[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.1.2


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

[Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected

[reichelt at gcc dot gnu dot org]

The following IMHO valid testcase is rejected on mainline and the 4.1
branch since a couple of days:

============================================================
template<typename> struct A;

template<typename T, int N> struct A<T[N]> {};

template<typename T, int N> struct A<const T[N]> {};

A<const int[1]> a;
============================================================

bug.cc:7: error: ambiguous class template instantiation for 'struct A<const int
[1]>'
bug.cc:3: error: candidates are: struct A<T [N]>
bug.cc:5: error:                 struct A<const T [N]>
bug.cc:7: error: aggregate 'A<const int [1]> a' has incomplete type and cannot
be defined

The testcase is similar to the testcase g++.dg/template/partial3.C
which still passes. The major difference is that we have a "int N"
here and an "unsigned N" in the testsuite.

Mark, this is due to your fix for PR 28595
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00991.html
Would you mind having a look?


-- 
           Summary: [4.1/4.2 regression] Template specialization with array
                    rejected
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Keywords: rejects-valid, monitored
          Severity: major
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-30 04:01 -------
A NON_LVALUE_EXPR is getting into the way:
(gdb) p debug_tree(max)
 <non_lvalue_expr 0xb7d387a0
    type <integer_type 0xb7cc9284 int public type_6 SI
        size <integer_cst 0xb7cb43d8 constant invariant 32>
        unit size <integer_cst 0xb7cb4168 constant invariant 4>
        align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0xb7cb4390
-2147483648> max <integer_cst 0xb7cb43a8 2147483647>
        pointer_to_this <pointer_type 0xb7cc9c38>>
    readonly constant invariant
    arg 0 <template_parm_index 0xb7d38740 type <integer_type 0xb7cc9284 int>
        readonly constant invariant
       index 1 level 1 orig_level 1>>


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-08-30 04:01:19
               date|                            |


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-30 05:25 -------
Here is the fix which I am testing, it just strips off the NON_LVALUE_EXPR that
fold will produce:
Index: pt.c
===================================================================
--- pt.c        (revision 116576)
+++ pt.c        (working copy)
@@ -10627,6 +10627,8 @@ unify (tree tparms, tree targs, tree par
                                     integer_type_node,
                                     arg_max,
                                     TREE_OPERAND (parm_max, 1));
+             /* Strip the NON_LVALUE_EXPRs that could show up via fold.  */
+             STRIP_TYPE_NOPS (arg_max);
              parm_max = TREE_OPERAND (parm_max, 0);
            }


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[mmitchel at gcc dot gnu dot org]

------- Comment #3 from mmitchel at gcc dot gnu dot org  2006-09-01 22:19 -------
There shouldn't be a NON_LVALUE_EXPR here at all; non-type template parameters
are lvalues only if they have reference type.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-09-01 22:24 -------
(In reply to comment #3)
> There shouldn't be a NON_LVALUE_EXPR here at all; non-type template parameters
> are lvalues only if they have reference type.

fold produces it because maybe_lvalue_p returns true for Language specific
trees
and fold is folding (template_parameter+1)-1.


-- 


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[mark at codesourcery dot com]

------- Comment #5 from mark at codesourcery dot com  2006-09-01 22:30 -------
Subject: Re:  [4.1/4.2 regression] Template specialization
 with array rejected

pinskia at gcc dot gnu dot org wrote:
> ------- Comment #4 from pinskia at gcc dot gnu dot org  2006-09-01 22:24 -------
> (In reply to comment #3)
>> There shouldn't be a NON_LVALUE_EXPR here at all; non-type template parameters
>> are lvalues only if they have reference type.
> 
> fold produces it because maybe_lvalue_p returns true for Language specific
> trees
> and fold is folding (template_parameter+1)-1.

So, that's what should be fixed.


-- 


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-09-02 01:36 -------
(In reply to comment #5)
> So, that's what should be fixed.
Except that means introducing a language hook which is only to be useful in one
place.
The other way of fixing this is not to call fold if we have a MINUS_EXPR with
the 2nd operand as 1, we just use the first.  Really I don't see any reason why
we should introduce a language hook when we can just strip the NON_LVALUE_EXPR
right after fold and introducing a language hook which will only help in one
specific case.
The real real way of fixing this is to move the C++ front-end's templates from
using trees and use something which is just specific to the C++ front-end and
we would not have to call fold here at all since we will just store the length
of the array instead of the "length-1".


-- 


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

Re: [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[Andrew Pinski]

On Fri, 2006-09-01 at 22:30 +0000, mark at codesourcery dot com wrote:
> So, that's what should be fixed.
Except that means introducing a language hook which
is only to be useful in one place.

The other way of fixing this is not to call fold if
we have a MINUS_EXPR with the 2nd operand as 1, we
just use the first.  Really I don't see any reason
why we should introduce a language hook when we
can just strip the NON_LVALUE_EXPR right after
fold and introducing a language hook which will
only help in one specific case.

The real real way of fixing this is to move the C++
front-end's templates from using trees and use something
which is just specific to the C++ front-end and we would
not have to call fold here at all since we will just store
the length of the array instead of the "length-1".

-- Pinski

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[pinskia at physics dot uc dot edu]

------- Comment #7 from pinskia at physics dot uc dot edu  2006-09-02 01:39 -------
Subject: Re:  [4.1/4.2 regression] Template specialization
        with array rejected

On Fri, 2006-09-01 at 22:30 +0000, mark at codesourcery dot com wrote:
> So, that's what should be fixed.
Except that means introducing a language hook which
is only to be useful in one place.

The other way of fixing this is not to call fold if
we have a MINUS_EXPR with the 2nd operand as 1, we
just use the first.  Really I don't see any reason
why we should introduce a language hook when we
can just strip the NON_LVALUE_EXPR right after
fold and introducing a language hook which will
only help in one specific case.

The real real way of fixing this is to move the C++
front-end's templates from using trees and use something
which is just specific to the C++ front-end and we would
not have to call fold here at all since we will just store
the length of the array instead of the "length-1".

-- Pinski


-- 


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[mark at codesourcery dot com]

------- Comment #8 from mark at codesourcery dot com  2006-09-02 03:50 -------
Subject: Re:  [4.1/4.2 regression] Template specialization
 with array rejected

pinskia at physics dot uc dot edu wrote:
> ------- Comment #7 from pinskia at physics dot uc dot edu  2006-09-02 01:39 -------
> Subject: Re:  [4.1/4.2 regression] Template specialization
>         with array rejected
> 
> On Fri, 2006-09-01 at 22:30 +0000, mark at codesourcery dot com wrote:
>> So, that's what should be fixed.

> Except that means introducing a language hook which
> is only to be useful in one place.

That's not necessarily a bad thing.  But, introducing NON_LVALUE_EXPRs 
that we are just going to throw away is a bad thing.

And, yes, if we can avoid generating MINUS_EXPRs, that would be even 
better.  In general, it might be better if range types were expressed as 
half-open intervals, rather than closed intervals, since then the number 
of elements in the array would be immediately available, and that's 
something often wants.

> The real real way of fixing this is to move the C++
> front-end's templates from using trees

You bring this up every so often, but I am totally unpersuaded.  Using 
trees is just fine for C++.  The advantages to not using trees would be 
interfacing to things other than GCC itself; there are no advantages 
within the compiler.  For example, if we didn't have trees for C++, we'd 
be totally unable to use fold.  In any case, this is entirely orthogonal 
to the issue at hand.


-- 


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-09-02 04:00 -------
Actually the other way to fix this is not to require NON_LVALUE_EXPR in the
first place by fixing the front-ends so they can figure out lvalueness without
depending on the tree structures.

Since Mark caused this and does not want the simple fix of removing
NON_LVALUE_EXPR after the fact, I am unassigning myself.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|pinskia at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2006-09-04 02:58 -------
What about this (which makes us not call fold unless we really need to):
Index: pt.c
===================================================================
--- pt.c        (revision 116671)
+++ pt.c        (working copy)
@@ -10631,10 +10631,15 @@ unify (tree tparms, tree targs, tree par
             not an integer constant.  */
          if (TREE_CODE (parm_max) == MINUS_EXPR)
            {
-             arg_max = fold_build2 (PLUS_EXPR,
-                                    integer_type_node,
-                                    arg_max,
-                                    TREE_OPERAND (parm_max, 1));
+             if (TREE_CODE (arg_max) == MINUS_EXPR
+                 && simple_cst_equal (TREE_OPERAND (arg_max, 1),
+                                      TREE_OPERAND (parm_max, 1)))
+               arg_max = TREE_OPERAND (arg_max, 0);
+             else
+               arg_max = fold_build2 (PLUS_EXPR,
+                                      integer_type_node,
+                                      arg_max,
+                                      TREE_OPERAND (parm_max, 1));
              parm_max = TREE_OPERAND (parm_max, 0);
            }

Though I wonder if the fold is even needed.  I am testing a couple of testcase
and see if it is.


-- 


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2006-09-04 03:02 -------
The fold is still needed.


-- 


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[mmitchel at gcc dot gnu dot org]

------- Comment #12 from mmitchel at gcc dot gnu dot org  2006-09-07 01:04 -------
Subject: Bug 28886

Author: mmitchel
Date: Thu Sep  7 01:04:07 2006
New Revision: 116736

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116736
Log:
        PR c++/28903
        * pt.c (tsubst): Use fold_non_dependent_expr to fold array
        dimensions.
        PR c++/28886
        * pt.c (unify): Avoid unnecessary calls to fold_build2 for array
        dimensions.

Added:
    trunk/gcc/testsuite/g++.dg/ext/vla3.C
    trunk/gcc/testsuite/g++.dg/template/array16.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/pt.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected

[mmitchel at gcc dot gnu dot org]

------- Comment #13 from mmitchel at gcc dot gnu dot org  2006-09-07 01:10 -------
Fixed in 4.2.0.


-- 


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

[Bug c++/28886] [4.1 regression] Template specialization with array rejected

[mmitchel at gcc dot gnu dot org]

------- Comment #15 from mmitchel at gcc dot gnu dot org  2006-09-08 00:05 -------
Fixed in GCC 4.1.2.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug c++/28886] [4.1 regression] Template specialization with array rejected

[mmitchel at gcc dot gnu dot org]

------- Comment #14 from mmitchel at gcc dot gnu dot org  2006-09-08 00:04 -------
Subject: Bug 28886

Author: mmitchel
Date: Fri Sep  8 00:04:42 2006
New Revision: 116768

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116768
Log:
        PR c++/28886
        * pt.c (unify): Avoid unnecessary calls to fold_build2 for array
        dimensions.
        PR c++/28886
        * g++.dg/template/array16.C: New test.

Added:
    branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/array16.C
Modified:
    branches/gcc-4_1-branch/gcc/cp/ChangeLog
    branches/gcc-4_1-branch/gcc/cp/pt.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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