--- 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=gccview=revrev=116736
Log:
PR c++/28903
* pt.c (tsubst): Use
--- 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
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|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
--- 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
--- 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
--- 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
--- 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 #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
On Fri, 2006-09-01 at 22:30 +, 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
--- 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 +, mark at codesourcery dot com wrote:
So, that's what should be fixed.
Except that means
--- 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
---
--- 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
--
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
--- 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
--- 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)
16 matches
Mail list logo
