[Bug c++/17232] New: classes and class template specializations treated differently w.r.t. core issue #337

[Bug c++/17232] New: classes and class template specializations treated differently w.r.t. core issue #337

[cludwig at cdc dot informatik dot tu-darmstadt dot de]

cludwig@lap200:~/C++/gcc3.4/tmp> LC_ALL=C g++ -v 
Reading specs from /opt/gcc/gcc-3.4.1/lib/gcc/i686-pc-linux-gnu/3.4.1/specs 
Configured with: ../gcc-3.4.1/configure --prefix=/opt/gcc/gcc-3.4.1 
--enable-threads=posix --enable-version-specific-runtime-libs 
--enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar 
--enable-concept-checks --enable-libstdcxx-debug --enable-c99 
--enable-libstdcxx-pch 
Thread model: posix 
gcc version 3.4.1 
 
cludwig@lap200:~/C++/gcc3.4/tmp> cat ./is_abstract_test.cc 
template<typename T> 
class A { 
  virtual void f() = 0; 
}; 
 
class B { 
  virtual void f() = 0; 
}; 
 
template<typename T> 
int g(T (*)[1]) { 
  return 0; 
} 
 
template<typename T> 
int g(...) { 
  return 1; 
} 
 
int main() { 
  return  (g< A<int> >(0) == g< B >(0)) ; 
} 
 
cludwig@lap200:~/C++/gcc3.4/tmp> ./is_abstract_test ; echo $? 
0 
 
According to http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#337, 
type deduction fails if it implies constructing an array of an abstract class. 
(This enables traits like boost::is_abstract<T>::value.) Therefore, above 
program is supposed to choose for both g< A<int> >() and g<B>() the second 
overload (the one that returns 1), whence the program's return value should be 
non-zero. 
 
However, g++ 3.4.1 chooses the first overload for g< A<int> >(). 
 
Regards 
 
Christoph

-- 
           Summary: classes and class template specializations treated
                    differently w.r.t. core issue #337
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: cludwig at cdc dot informatik dot tu-darmstadt dot de
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[cludwig at cdc dot informatik dot tu-darmstadt dot de]

------- Additional Comments From cludwig at cdc dot informatik dot tu-darmstadt dot de  2004-08-29 17:58 -------
Created an attachment (id=7001)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7001&action=view)
testcase


-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-29 18:42 -------
I don't presently have the time to figure things out, but here are 
a few data points: 
  gcc2.95, 3.2.3, and 3.3.4 return 1 
  gcc3.4.1, gcc mainline, and icc8 return 0 
 
Note also that the declaration 
  int g(T (*)[1]) 
is taking an argument of type pointer to array of T. However, as the 
types you use are abstract, there can't be any arrays of these types 
and this declaration should probably never match. 
 
That doesn't invalidate your point, though, that the compiler should 
probably treat template instances and non-template classes equivalently. 
 
W. 

-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[cludwig at cdc dot informatik dot tu-darmstadt dot de]

------- Additional Comments From cludwig at cdc dot informatik dot tu-darmstadt dot de  2004-08-29 18:57 -------
Subject: Re:  classes and class template specializations treated differently w.r.t. core issue #337

On Sun, Aug 29, 2004 at 06:42:54PM -0000, bangerth at dealii dot org wrote:
> 
> I don't presently have the time to figure things out, but here are 
> a few data points: 
>   gcc2.95, 3.2.3, and 3.3.4 return 1 
>   gcc3.4.1, gcc mainline, and icc8 return 0 
>  
> Note also that the declaration 
>   int g(T (*)[1]) 
> is taking an argument of type pointer to array of T. However, as the 
> types you use are abstract, there can't be any arrays of these types 
> and this declaration should probably never match. 

I agree. 

> That doesn't invalidate your point, though, that the compiler should 
> probably treat template instances and non-template classes equivalently. 

To avoid misunderstandings: gcc 3.3.1 also returns 1. But if you
change the return statement into 

  return  (g< A<int> >(0) == 1) && (g< B >(0) == 1);

then the executable generated by gcc 3.3.1 returns 0 because
gcc 3.3.1 does not implement the resolution of core issue 337 at all.

Regards

Christoph



-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-30 12:30 -------
Confirmed.

The problem is that A<int> was not instantiated at the point of call. So the 
compiler does not know yet if A<int> is an abstract type or not -- it will have 
to instantiate that to do so. Now, I am not sure we should force an 
instantiation just because we are trying to form an array type and we need to 
check for abstractness, I fear this requires a clarification from C++ gurus.

The simple workaround is to force an instantiation of the class to happen 
before the call. I don't know if it is possible in your application, though. 
For the testcase, you need to add a "template struct A<int>;" somewhere before 
the call.

What EDG does is to simply ignore the abstract constraint in this situation, 
and allow the call. It will then error out when the array is first used in the 
body of the function as the underlying type is abstract -- but it seems to me 
as a violation of [dcl.array]/1 which says that it is invalid to (just) declare 
an array to abstract type.

I think you are better off raising this issue with comp.std.c++, and get back 
to us. If there is agreement that EDG is wrong and the template deduction 
should be rejected through an instantiation of the argument, I can implement 
this solution into the compiler (I implemented DR 337 in the first place).

I also would like to know if this affects your application in a way that causes 
a regression (that is, 3.3 works but 3.4 does not), because your testcase is 
wisely constructed as a regression, but the actual bug is not (since DR 337 was 
first implemented in 3.4, and has this "bug" since then).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giovannibajo at libero dot
                   |                            |it
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |accepts-invalid, rejects-
                   |                            |valid, wrong-code
      Known to fail|                            |2.95.3 3.0.4 3.2.3 3.3.3
                   |                            |3.4.0 3.5.0
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-30 12:30:24
               date|                            |


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[cludwig at cdc dot informatik dot tu-darmstadt dot de]

------- Additional Comments From cludwig at cdc dot informatik dot tu-darmstadt dot de  2004-08-30 13:22 -------
Subject: Re:  classes and class template specializations treated differently w.r.t. core issue #337

On Mon, Aug 30, 2004 at 12:30:28PM -0000, giovannibajo at libero dot it wrote:
> The problem is that A<int> was not instantiated at the point of call. So the 
> compiler does not know yet if A<int> is an abstract type or not -- it will have 
> to instantiate that to do so. Now, I am not sure we should force an 
> instantiation just because we are trying to form an array type and we need to 
> check for abstractness, I fear this requires a clarification from
> C++ gurus.

IMHO the class template needs to be instantiated:

  14.7.1/p4 (Implicit Instantiation)

  A class template specialization is implicitly instantiated if the
  class type is used in a context that requires a completely defined
  object type or if the completeness of the class type affects the
  semantics of the program; in particular, if an expression whose type
  is a class template specialization is involved in overload
  resolution, pointer conversion, pointer to member conversion, the
  class template specialization is implicitly instantiated (3.2);
  [...]

In my testcase, the semantics of the program depends on the
completeness of A<int> and the class template specialization is
obviously involved in overload resolution. I therefore think an
implicit specialization is warranted.

> The simple workaround is to force an instantiation of the class to happen 
> before the call. I don't know if it is possible in your application, though. 
> For the testcase, you need to add a "template struct A<int>;" somewhere before 
> the call.

Unfortunately, explicit instantiation is not a viable alternative in
my project. But I have another workaround, see below.

> What EDG does is to simply ignore the abstract constraint in this situation, 
> and allow the call. It will then error out when the array is first used in the 
> body of the function as the underlying type is abstract -- but it seems to me 
> as a violation of [dcl.array]/1 which says that it is invalid to (just) declare 
> an array to abstract type.

Do I understand you correctly, EDG based compilers will call the first
overload for A<int>? Since my testcase never actually uses the array,
there won't be any error and the function call g< A<int> >(0) will
return 0? (I don't have access to an EDG based compiler whence I
cannot easily test it myself.)
 
> I think you are better off raising this issue with comp.std.c++, and get back 
> to us. If there is agreement that EDG is wrong and the template deduction 
> should be rejected through an instantiation of the argument, I can implement 
> this solution into the compiler (I implemented DR 337 in the first place).

Sure, I will post this problem to comp.std.c++.

> I also would like to know if this affects your application in a way that causes 
> a regression (that is, 3.3 works but 3.4 does not), because your testcase is 
> wisely constructed as a regression, but the actual bug is not (since DR 337 was 
> first implemented in 3.4, and has this "bug" since then).

I don't think you can call it a regression.

I am using the new Boost serialization library that needs to handle
abstract classes differently. For gcc >= 3.4 it uses the
boost::is_abstract type trait to recognize abstract base classes and
it is therefore affected by this problem if the abstract base class is
in fact a template specialization.

For gcc <= 3.3.x it is known that DR 337 is not implemented whence
boost::is_abstract fails. The user must explicitly mark abstract
classes (essentially by an explicit specialization of
boost::is_abstract) if the serialization library is used with 
gcc <= 3.3.x.

Regards

Christoph


-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-30 14:45 -------
(In reply to comment #6)

> IMHO the class template needs to be instantiated:
>   14.7.1/p4 (Implicit Instantiation)
>   [...]

I'm with you here, but we need language lawyers to confirm.

> Do I understand you correctly, EDG based compilers will call the first
> overload for A<int>? 

Yes.

> (I don't have access to an EDG based compiler whence I
> cannot easily test it myself.)

http://www.comeaucomputing.com/tryitout. You have to change your test into a 
compile-time only test though. For instance, remove the catch-all ellipsis 
overload and see if the compilation succeeds or fails because there is no 
viable functions (see also the testcase in my patch, which I have attacched to 
this bug).

> Sure, I will post this problem to comp.std.c++.

Thanks, get back to us when you get an answer.


> For gcc <= 3.3.x it is known that DR 337 is not implemented whence
> boost::is_abstract fails. The user must explicitly mark abstract
> classes (essentially by an explicit specialization of
> boost::is_abstract) if the serialization library is used with 
> gcc <= 3.3.x.

I see you raised this on the Boost list. Maybe it is worth disabling
is_abstract for GCC 3.4, as the problem will be fixed in 3.5.0 only.

I apologize for not catching this simple bug back when I added support for the 
DR, I usually test both template and non-template cases...

-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-30 16:05 -------
So do we agree that the problem in this PR is really this: 
- for the non-template, the compiler realizes that B is abstract 
  and that therefore no array type can exist; it therefore rejects 
  the template version of g and goes with the general one 
- for the template class A, the compiler doesn't realize the  
  abstractness and therefore goes with the template version of g 
Is this indeed the reason the testcase fails? I double-checked that 
if I remove the '=0' declaration in the two classes, that the testcase 
really succeeds. 
 
W. 

-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[cludwig at cdc dot informatik dot tu-darmstadt dot de]

------- Additional Comments From cludwig at cdc dot informatik dot tu-darmstadt dot de  2004-08-30 16:56 -------
Subject: Re:  classes and class template specializations treated differently w.r.t. core issue #337

On Mon, Aug 30, 2004 at 04:05:26PM -0000, bangerth at dealii dot org wrote:
> 
> So do we agree that the problem in this PR is really this: 
> - for the non-template, the compiler realizes that B is abstract 
>   and that therefore no array type can exist; it therefore rejects 
>   the template version of g and goes with the general one 
> - for the template class A, the compiler doesn't realize the  
>   abstractness and therefore goes with the template version of g 
> Is this indeed the reason the testcase fails?

Yes, that's correct.

Perhaps the testcase becomes clearer if you change main() into

  int main() { 
    return  g< A<int> >(0) + 2 * g< B >(0) ; 
  } 

I'd expect the return value 3 since both classes are abstract and (IMO)
the second overload should be chosen in both cases according to the
resolution of DR#337 and the SFINAE principle.
But gcc 3.4.1 returns 2, exhibiting that the compiler chose the
overloads g< A<int> >(A<int>(*)[1]) and g< B >(...),

> I double-checked that 
> if I remove the '=0' declaration in the two classes, that the testcase 
> really succeeds. 

That's correct behaviour. Once the classes are no longer abstract the
substitution T = B and T = A<int> into T(*)[1] yields a valid
expression and g(T(*)[1]) can take part in overload resolution. DR#337
does not apply. 

Since any match is considered better than the ellipsis, g(T(*)[1]) is
chosen both for T = B and T = A<int>.

Regards

Christoph


-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-30 20:10 -------
Yes, Cristoph is right. Since the original testcase is a little confusing, this 
is the minimized version posted with my patch:

------------------------------------
template<typename T>
class A { 
  virtual void f() = 0;
}; 
 
template<typename T>
void g(T (*a)[1]) {}

int main() {
  g<A<int> >(0);  // { dg-error "no matching function" }
}
------------------------------------

This should be rejected by a conforming compiler, to the best of my 
understaning, because of [dcl.array]/1 and [temp.inst]/4. EDG fails to reject 
this. I am waiting for language lawyers though before running the patch through 
testing.

I'm CC'ing Jason and GDR, maybe they have a little time to provide some legal 
comments on this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com, gdr
                   |                            |at gcc dot gnu dot org


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-30 20:56 -------
In my view, 14.7.1/4 clearly indicates that the type should be instantiated. 
In particular, the sub-sentence on overload resolution seems imminent to me. 
 
The question whether the resulting (abstract) type will then cause us to 
reject the template function is a different matter and covered by DR 337. 
It is only in WP status, but it seems clear to me that it will eventually 
be adopted, and gcc seems to have it implemented already anyway, so it 
seems safe to take it as a basis. In that case, if my view of 14.7.1 is 
correct, then we erroneously miscompile the program, as is EDG. 
 
W. 

-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[jason at redhat dot com]

------- Additional Comments From jason at redhat dot com  2004-08-30 22:12 -------
Subject: Re:  classes and class template specializations
 treated differently w.r.t. core issue #337

I think that while the overloading makes the question more interesting,
there is a simpler form:

  template<typename T>
  class A { 
    virtual void f() = 0;
  }; 

  A<int>(*p)[1];

Is the compiler required to diagnose this?  If so, simply creating an array
type requires that the element type be instantiated.  I think that this is
the right answer, but I also think it's worth discussing with the
committee.

Jason


-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-30 23:15 -------
Subject: Re:  classes and class template specializations treated differently w.r.t. core issue #337

jason at redhat dot com wrote:

>   template<typename T>
>   class A {
>     virtual void f() = 0;
>   };
>
>   A<int>(*p)[1];
>
> Is the compiler required to diagnose this?  If so, simply creating an
> array type requires that the element type be instantiated.

Yes, [dcl.array]/1 tells us that it's invalid to create an array type if the
element type is abstract, and [temp.inst]/1 tells us that there has to be an
implicit instantiation whenever the completeness of the type affects the
semantic of the program (and we know that we need an instantiation to check if
the class is really abstract or not).

>I think that this is the right answer, but I also think it's worth discussing
with the
> committee.

I think the submitter was going to raise the issue on comp.std.c++, but maybe
you can raise this directly with the committee? When we get a consensus, I can
test & submit the patch I attacched to this bug.

Giovanni Bajo




-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[cludwig at cdc dot informatik dot tu-darmstadt dot de]

------- Additional Comments From cludwig at cdc dot informatik dot tu-darmstadt dot de  2004-09-06 07:03 -------
Subject: Re:  classes and class template specializations treated differently w.r.t. core issue #337

On Mon, Aug 30, 2004 at 11:15:33PM -0000, giovannibajo at libero dot it wrote:
> I think the submitter was going to raise the issue on comp.std.c++, but maybe
> you can raise this directly with the committee? When we get a consensus, I can
> test & submit the patch I attacched to this bug.

My post to comp.std.c++ drew only one reply; but in this reply Gabriel
Dos Reis confirmed that my understanding of 14.7.1 is correct and this
is indeed a bug in gcc. See
<URL:http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=m3656v637d.fsf%40merlin.cs.tamu.edu>.

Regards

Christoph


-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-09-06 13:39 -------
Thanks. Patch submitted for review:
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00549.html


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-09-06 13:43 -------
(In reply to comment #12)
Jason:

>   template<typename T>
>   class A { 
>     virtual void f() = 0;
>   }; 
>   A<int>(*p)[1];
>
> Is the compiler required to diagnose this?  If so, simply creating an array
> type requires that the element type be instantiated.  I think that this is
> the right answer, but I also think it's worth discussing with the
> committee.

I agree too. GCC does not diagnose this case yet, we prolly need to complete 
the type in create_array_type_for_decl. If you want, I can prepare such a 
patch, and this issue can be tracked in another PR.


-- 


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

[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-09-27 12:02 -------
Patch needs updateing. My last fix proposed here:
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00783.html
is not complete. I need to rethink what we want GCC to do in both the tentative 
and non-tentative substitution mode.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |
      Known to fail|2.95.3 3.0.4 3.2.3 3.3.3    |2.95.3 3.0.4 3.2.3 3.3.3
                   |3.4.0 4.0                   |3.4.0 4.0.0


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