--- Comment #13 from rguenth at gcc dot gnu dot org 2007-04-21 16:37
---
The interesting thing is that we
Created value VH.0 for (unnamed-unsigned:4) 31
The bug (compared to the trunk) is, that tree-ssa-pre.c:try_look_through_load
on the 4.2 branch manages to propagate the 31 while
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-04-21 16:56
---
Indeed.
int main(void){
s.b6 = 31;
s.b4 = s.b6 + s.b6;
s.b6 = s.b4;
return s.b6 == 15 ? 0 : 1;
}
Created value VH.0 for 31 + 31
...
bb 2:
s.b6 = 31;
D.1530_3 = 31;
D.1531_4 = 31;
D.1530_5 = 31;
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-04-21 16:58
---
See comment #13.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-04-21 18:44
---
Subject: Bug 31136
Author: rguenth
Date: Sat Apr 21 18:43:57 2007
New Revision: 124019
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124019
Log:
2007-04-21 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-04-21 18:47
---
Subject: Bug 31136
Author: rguenth
Date: Sat Apr 21 18:47:13 2007
New Revision: 124020
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124020
Log:
2007-04-21 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-04-21 18:53
---
Fixed. I split the remaining FRE problems to a new PR31651.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-03-26 05:43
---
I agree with Joseph that STRIP_SIGN_NOPS should not be removing changes in
precision that may change the value and that, indeed, mode is probably being
used as an inaccurate proxy for precision.
--
On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
The problematic STRIP_SIGN_NOPS() call is from fold_unary()
which is called from try_combine_conversion() in tree-ssa-pre.c.
STRIP_SIGN_NOPS() is called with the expression:
No, STRIP_SIGN_NOPS is correct,
--- Comment #8 from pinskia at gmail dot com 2007-03-23 07:57 ---
Subject: Re: [4.2 Regression] FRE ignores bit-field truncation (C and C++
front-end don't produce bit-field truncation
On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
The
On 3/23/07, Andrew Pinski [EMAIL PROTECTED] wrote:
On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
The problematic STRIP_SIGN_NOPS() call is from fold_unary()
which is called from try_combine_conversion() in tree-ssa-pre.c.
STRIP_SIGN_NOPS() is called
--- Comment #9 from pinskia at gmail dot com 2007-03-23 08:01 ---
Subject: Re: [4.2 Regression] FRE ignores bit-field truncation (C and C++
front-end don't produce bit-field truncation
On 3/23/07, Andrew Pinski [EMAIL PROTECTED] wrote:
On 23 Mar 2007 05:01:00 -, spark at gcc dot
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-23 08:17
---
The good question is why does FRE not do anything on the trunk:
s.b6 = 31;
D.1597_1 = s.b6;
that really should be optimized at the FRE level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
--- Comment #11 from joseph at codesourcery dot com 2007-03-23 13:41
---
Subject: Re: [4.2 Regression] FRE ignores
bit-field truncation (C and C++ front-end don't produce bit-field truncation
On Fri, 23 Mar 2007, pinskia at gmail dot com wrote:
No, STRIP_SIGN_NOPS is correct, just
--- Comment #6 from jsm28 at gcc dot gnu dot org 2007-03-23 03:45 ---
Analysis: http://gcc.gnu.org/ml/gcc/2007-03/msg00867.html
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from spark at gcc dot gnu dot org 2007-03-23 05:00 ---
Follow up on Joseph's analysis:
The problematic STRIP_SIGN_NOPS() call is from fold_unary()
which is called from try_combine_conversion() in tree-ssa-pre.c.
STRIP_SIGN_NOPS() is called with the expression:
15 matches
Mail list logo
