* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
@ 2006-08-29 10:51 ` reichelt at gcc dot gnu dot org
2006-08-30 4:01 ` pinskia at gcc dot gnu dot org
` (15 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: reichelt at gcc dot gnu dot org @ 2006-08-29 10:51 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
2006-08-29 10:51 ` [Bug c++/28886] " reichelt at gcc dot gnu dot org
@ 2006-08-30 4:01 ` pinskia at gcc dot gnu dot org
2006-08-30 5:25 ` pinskia at gcc dot gnu dot org
` (14 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-08-30 4:01 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
2006-08-29 10:51 ` [Bug c++/28886] " reichelt at gcc dot gnu dot org
2006-08-30 4:01 ` pinskia at gcc dot gnu dot org
@ 2006-08-30 5:25 ` pinskia at gcc dot gnu dot org
2006-09-01 22:19 ` mmitchel at gcc dot gnu dot org
` (13 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-08-30 5:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (2 preceding siblings ...)
2006-08-30 5:25 ` pinskia at gcc dot gnu dot org
@ 2006-09-01 22:19 ` mmitchel at gcc dot gnu dot org
2006-09-01 22:24 ` pinskia at gcc dot gnu dot org
` (12 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2006-09-01 22:19 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (3 preceding siblings ...)
2006-09-01 22:19 ` mmitchel at gcc dot gnu dot org
@ 2006-09-01 22:24 ` pinskia at gcc dot gnu dot org
2006-09-01 22:30 ` mark at codesourcery dot com
` (11 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-09-01 22:24 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (4 preceding siblings ...)
2006-09-01 22:24 ` pinskia at gcc dot gnu dot org
@ 2006-09-01 22:30 ` mark at codesourcery dot com
2006-09-02 1:39 ` Andrew Pinski
2006-09-02 1:37 ` pinskia at gcc dot gnu dot org
` (10 subsequent siblings)
16 siblings, 1 reply; 19+ messages in thread
From: mark at codesourcery dot com @ 2006-09-01 22:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-09-01 22:30 ` mark at codesourcery dot com
@ 2006-09-02 1:39 ` Andrew Pinski
0 siblings, 0 replies; 19+ messages in thread
From: Andrew Pinski @ 2006-09-02 1:39 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (5 preceding siblings ...)
2006-09-01 22:30 ` mark at codesourcery dot com
@ 2006-09-02 1:37 ` pinskia at gcc dot gnu dot org
2006-09-02 1:39 ` pinskia at physics dot uc dot edu
` (9 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-09-02 1:37 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (6 preceding siblings ...)
2006-09-02 1:37 ` pinskia at gcc dot gnu dot org
@ 2006-09-02 1:39 ` pinskia at physics dot uc dot edu
2006-09-02 3:51 ` mark at codesourcery dot com
` (8 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: pinskia at physics dot uc dot edu @ 2006-09-02 1:39 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (7 preceding siblings ...)
2006-09-02 1:39 ` pinskia at physics dot uc dot edu
@ 2006-09-02 3:51 ` mark at codesourcery dot com
2006-09-02 4:01 ` pinskia at gcc dot gnu dot org
` (7 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: mark at codesourcery dot com @ 2006-09-02 3:51 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (8 preceding siblings ...)
2006-09-02 3:51 ` mark at codesourcery dot com
@ 2006-09-02 4:01 ` pinskia at gcc dot gnu dot org
2006-09-04 2:58 ` pinskia at gcc dot gnu dot org
` (6 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-09-02 4:01 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (9 preceding siblings ...)
2006-09-02 4:01 ` pinskia at gcc dot gnu dot org
@ 2006-09-04 2:58 ` pinskia at gcc dot gnu dot org
2006-09-04 3:02 ` pinskia at gcc dot gnu dot org
` (5 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-09-04 2:58 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (10 preceding siblings ...)
2006-09-04 2:58 ` pinskia at gcc dot gnu dot org
@ 2006-09-04 3:02 ` pinskia at gcc dot gnu dot org
2006-09-04 18:57 ` mmitchel at gcc dot gnu dot org
` (4 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-09-04 3:02 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (11 preceding siblings ...)
2006-09-04 3:02 ` pinskia at gcc dot gnu dot org
@ 2006-09-04 18:57 ` mmitchel at gcc dot gnu dot org
2006-09-07 1:05 ` mmitchel at gcc dot gnu dot org
` (3 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2006-09-04 18:57 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (12 preceding siblings ...)
2006-09-04 18:57 ` mmitchel at gcc dot gnu dot org
@ 2006-09-07 1:05 ` mmitchel at gcc dot gnu dot org
2006-09-07 1:11 ` mmitchel at gcc dot gnu dot org
` (2 subsequent siblings)
16 siblings, 0 replies; 19+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2006-09-07 1:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (13 preceding siblings ...)
2006-09-07 1:05 ` mmitchel at gcc dot gnu dot org
@ 2006-09-07 1:11 ` mmitchel at gcc dot gnu dot org
2006-09-08 0:05 ` [Bug c++/28886] [4.1 " mmitchel at gcc dot gnu dot org
2006-09-08 0:05 ` mmitchel at gcc dot gnu dot org
16 siblings, 0 replies; 19+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2006-09-07 1:11 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (14 preceding siblings ...)
2006-09-07 1:11 ` mmitchel at gcc dot gnu dot org
@ 2006-09-08 0:05 ` mmitchel at gcc dot gnu dot org
2006-09-08 0:05 ` mmitchel at gcc dot gnu dot org
16 siblings, 0 replies; 19+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2006-09-08 0:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/28886] [4.1 regression] Template specialization with array rejected
2006-08-29 10:51 [Bug c++/28886] New: [4.1/4.2 regression] Template specialization with array rejected reichelt at gcc dot gnu dot org
` (15 preceding siblings ...)
2006-09-08 0:05 ` [Bug c++/28886] [4.1 " mmitchel at gcc dot gnu dot org
@ 2006-09-08 0:05 ` mmitchel at gcc dot gnu dot org
16 siblings, 0 replies; 19+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2006-09-08 0:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 19+ messages in thread