[Bug c++/21008] New: Acess failure in accessing data member of base class from derived template class

[Bug c++/21008] New: Acess failure in accessing data member of base class from derived template class

[nicoara at roguewave dot com]

$ uname -srm
Linux 2.6.11.4 i686

$ g++ -v
Reading specs from /opt/compilers/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/opt/compilers/gcc-3.4.3
--enable-shared --enable-threads --enable-languages=c,c++
Thread model: posix
gcc version 3.4.3


Copy and paste at prompt:

$ cat > t.cpp << EOF

struct A
{
protected:
    int foo_;
};


template <class T>
struct B : public A
{
};

template <class T>
struct C : protected B<T>
{
    int foo () {
        return A::foo_;
    }
};
 
EOF

Compilation of the above with:

$ g++ -c t.cpp

results in:

t.cpp: In member function `int C<T>::foo()':
t.cpp:4: error: object missing in reference to `A::foo_'
t.cpp:17: error: from this location

Thanks,
Liviu

-- 
           Summary: Acess failure in accessing data member of base class
                    from derived template class
           Product: gcc
           Version: 3.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: nicoara at roguewave dot com
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-13 22:04 -------
Ok, I don't know if this is valid code (I think it is invalid as foo_ is qualified and not dependent, even 
though ICC and Comeau does not reject this):
struct A { int foo_; };
template <class T> struct B : public A {};
template<> struct B<int> {};
template <class T>
struct C : B<T>
{
    int foo () {
        return A::foo_;
    }
};


Take the above code and add:
C<int> a;
void f(void) {a.foo();}

ICC only rejects the code at  instantiation time which seems wrong.

Someone else will have to comment to make sure that I got my analysis right.

The way to "fix" the if the code is invalid is to do B<T>::A::_foo or this->_foo.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
            Summary|Acess failure in accessing  |[3.4/4.0/4.1 Regression]
                   |data member of base class   |Acess failure in accessing
                   |from derived template class |data member of base class
                   |                            |from derived template class
   Target Milestone|---                         |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-04-15 05:29 -------
A::foo_ is not template-dependent, so it is looked up and bound at the time 
of template definition, not at instantiation time. Because template-dependent 
base classes are not visible at the time, the access is assumed to be from 
the outside, not within the class hierarchy through this->, and the error, 
though surprising, is correct. 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[sebor at roguewave dot com]

------- Additional Comments From sebor at roguewave dot com  2005-04-19 15:39 -------
I discussed this with Mike Miller of EDG. His response to my query on the issue
(copied with his permission) is below.

Mike Miller wrote:
...
> There were a couple of different examples in that thread, 
> so just to avoid confusion, here's the one I'll refer to:
> 
>     struct A {
>       int foo_;
>     };
>     template <typename T> struct B: public A { };
>     template <typename T> struct C: B<T> {
>       int foo() {
>         return A::foo_;  // #1
>       }
>     };
> 
> The question is how the reference on line #1 is treated. Wolfgang's 
> analysis isn't quite right.  While it's true that "A" is non-dependent 
> and thus is bound to ::A at template definition time, that is 
> irrelevant.  When C<int>::foo() (for instance) is instantiated, it turns 
> out that the reference to ::A::foo_ is, in fact, a non-static member of 
> a base class (9.3.1p3), so the reference is transformed into 
> (*this).::A::foo_ and there is no error.  This is not a violation of 
> 14.6.2p3 -- there's no lookup in a dependent base class involved, as 
> Wolfgang's comments assume, and the description "the access is assumed 
> to be from the outside, not within the class hierarchy through this->" 
> doesn't accurately describe how 9.3.1p3 works.
> 
> In fact, though, this just sort of happens to work because A is both 
> visible in the definition context and a base class of the instantiated 
> template.  If you add an explicit specialization
> 
>     template<> struct B<int> { };
> 
> as suggested in Andrew's comment, so A is not a base class, or if you 
> change the program so that A is not visible in the definition context 
> (by making it a member of a namespace, for instance), we do report an 
> error in the instantiated C<int>::foo().  (There's no requirement to 
> report errors in uninstantiated templates, of course, contrary to 
> Andrew's observation.)
> 
> This is sort of contrary to the "spirit" of two-stage lookup, though -- 
> Wolfgang's expectation is not unreasonable, I think, even though the 
> details of his reasoning are incorrect.  I'm probably going to open a 
> core issue on this, especially in light of the differences between 
> implementations.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[sebor at roguewave dot com]

------- Additional Comments From sebor at roguewave dot com  2005-04-19 15:41 -------
Here's a followup email from Mike with some calarifying comments:

Mike Miller wrote:
> Martin Sebor wrote:
> 
>> Thanks a lot for the detailed analysis! I wonder if your reasoning
>> would be the same given a slightly different test case (one that's
>> closer to the original in comment #1):
>>
>>>
>>>     struct A {
>>
>>
>>       protected:     // <<< ADDED <<<
>>
>>>       int foo_;
>>>     };
>>>     template <typename T> struct B: public A { };
>>>     template <typename T> struct C: B<T> {
>>>       int foo() {
>>>         return A::foo_;  // #1
>>>       }
>>>     };
> 
> 
> No, I don't think that changes things.  Again, the situation is the 
> same: whether A is the global class or the injected-class-name doesn't 
> affect whether C<int> (or whatever) has access to A::foo_.  (There are 
> cases where it does matter, but this isn't one of them.  Those typically 
> involve private or protected inheritance, where the access from 
> "outside" is greater than the inherited access.)
> 
> The general principle is that non-dependent names are looked up and 
> bound in the definition context (14.6.3), but that's really the only 
> semantic effect.  In cases like this one, it's as if "A" were replaced 
> by "::A".  If the result of using "::A" is well-formed, then the version 
> with just "A" is, too.
> 
>> But if an implementation is permitted to diagnose access violations
>> at definition time wouldn't the gcc compilation error be justified?
> 
> 
> I think the general rule is that you should only issue a diagnostic if 
> you can tell that no well-formed instantiation is possible (14.6p7).  In 
> these cases, at least some specializations will have well-formed 
> instantiations, so no diagnostic is permitted.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-04-19 18:25 -------
Martin & Mike, 
I'm happy to reopen this PR. I understand your analysis, and in fact thought 
about it when I wrote my comment. Independently of whether it may be strictly 
mandated by the standard, I do have to admit that I find it confusing to see 
the semantics of something change at the time of instantiation, even though 
it was already bound at template definition time. I do think that this is 
a further complication of the already not quite so intuitive two-stage 
name lookup rules. 
 
But I guess that's immaterial. We're not into intuitive things, but into 
the letter of the law. Some people in this country already claim that  
lawyers stray too far from the letter of the law anyway, so we won't give 
them more reason to complain. 
 
Incidentally, two question: 
a) your reference to 9.3.1p3 must have been to something else. In TC1,  
   9.3.1 is on const and volatile member functions. 
 
b) how does your interpretation affect the validity of the following program: 
------------------ 
struct A { 
    int foo_; 
}; 
typedef int A::* pAi; 
 
template <typename T> struct B: public A { }; 
template <typename T> struct C: B<T> { 
     pAi foo() { 
      return &A::foo_; 
    } 
}; 
----------------- 
If A::foo_ refers to the member variable *of the present object*, then  
taking its address returns an int*, not an "int A::*" object, right? However, 
I can't seem to find a compiler that would reject the code. 
 
Thanks 
  Wolfgang 
 
 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sebor at roguewave dot com,
                   |                            |bangerth at dealii dot org
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[william dot m dot miller at gmail dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |william dot m dot miller at
                   |                            |gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[william dot m dot miller at gmail dot com]

------- Additional Comments From william dot m dot miller at gmail dot com  2005-04-20 20:14 -------
Responses to Wolfgang's two questions:

a) You're right; I was looking at the current WP rather than the 2003 
Standard.  Sorry.  It's 9.3.1p2 in the 2003 Standard (the change from troff to 
LaTeX resulted in some paragraphs being numbered differently, and I didn't 
notice that this was one of those cases).

b) No, unary & applied to a qualified-id that names a non-static member is 
always a pointer to member (5.3.1p2-3), regardless of whether the qualifier is 
an injected-class-name or an ordinary class-name.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[lerdsuwa at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lerdsuwa at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] [DR515] Access failure in accessing data member of base class from derived template class

[lerdsuwa at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[3.4/4.0/4.1 Regression]    |[3.4/4.0/4.1 Regression]
                   |Acess failure in accessing  |[DR515] Access failure in
                   |data member of base class   |accessing data member of
                   |from derived template class |base class from derived
                   |                            |template class


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] [DR515] Access failure in accessing data member of base class from derived template class

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.4                       |3.4.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] [DR515] Access failure in accessing data member of base class from derived template class

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-07-06 17:03 -------
Postponed until 4.0.2.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.5                       |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] [DR515] Access failure in accessing data member of base class from derived template class

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.2                       |4.0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] [DR515] Access failure in accessing data member of base class from derived template class

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2005-10-17 14:50 -------
Confirmed, and .....


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-10-17 14:50:25
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] [DR515] Access failure in accessing data member of base class from derived template class

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2005-10-17 14:51 -------
And removing target milestone and suspending since the DR report is still
active:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#515


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED
   Target Milestone|4.0.3                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008

[Bug c++/21008] [3.4/4.0/4.1 Regression] [DR515] Access failure in accessing data member of base class from derived template class

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P5
   Target Milestone|---                         |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008