public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
[not found] <bug-42512-4@http.gcc.gnu.org/bugzilla/>
@ 2022-10-25 11:40 ` cvs-commit at gcc dot gnu.org
0 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-25 11:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:4c5b1160776382772fc0a33130dfaf621699fdbf
commit r13-3486-g4c5b1160776382772fc0a33130dfaf621699fdbf
Author: Richard Biener <rguenther@suse.de>
Date: Mon Oct 24 08:52:12 2022 +0200
tree-optimization/107176 - SCEV analysis association issue
The following fixes a wrong-code issue caused by SCEV analysis
associating an addition due trying to use tail-recursion in
follow_ssa_edge_expr. That causes us to apply a conversion at
the wrong point and thus miscompute the scalar evolution of
an induction variable. This reverts the PR66375 fix and
revisits the PR42512 fix by keeping the evolution symbolic
up to the point we process the first linear function when
we then can check for the supported cases and substitute the
whole symbolic expression with the built chrec substituting
the proper initial value.
To simplify passing around things and to clarify scoping of
the involved functions this change wraps the SCEV DFS walking
code into a class.
PR tree-optimization/107176
PR tree-optimization/66375
PR tree-optimization/42512
* tree-scalar-evolution.cc (follow_ssa_edge_expr): Revert
the PR66375 fix, do not not associate PLUS_EXPR to be able
to use tail-recursion.
(follow_ssa_edge_binary): Likewise.
(interpret_loop_phi): Revert PR42512 fix, do not throw
away analyze_evolution_in_loop result after the fact.
(follow_ssa_edge_expr): When reaching halting_phi initalize
the evolution to the symbolic value of the PHI result.
(add_to_evolution_1): When adding the first evolution verify
we can handle the expression wrapping the symbolic evolution
and replace that in full using the initial condition.
(class scev_dfs): New, contains ...
(follow_ssa_edge_expr, follow_ssa_edge_binary,
follow_ssa_edge_in_condition_phi_branch,
follow_ssa_edge_in_condition_phi,
follow_ssa_edge_inner_loop_phi,
add_to_evolution, add_to_evolution_1): ... these with
loop and halting_phi arguments in class data.
(scev_dfs::get_ev): New toplevel DFS entry, start with
a chrec_dont_know evolution.
(analyze_evolution_in_loop): Use scev_dfs.
* gcc.dg/torture/pr107176.c: New testcase.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (12 preceding siblings ...)
2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
@ 2010-02-07 4:49 ` hjl at gcc dot gnu dot org
13 siblings, 0 replies; 16+ messages in thread
From: hjl at gcc dot gnu dot org @ 2010-02-07 4:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from hjl at gcc dot gnu dot org 2010-02-07 04:45 -------
Subject: Bug 42512
Author: hjl
Date: Sun Feb 7 04:41:22 2010
New Revision: 156562
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156562
Log:
Backport testcases from mainline to 4.4.
2010-02-06 H.J. Lu <hongjiu.lu@intel.com>
Backport from mainline:
2010-02-05 Dodji Seketeli <dodji@redhat.com>
PR c++/42915
* g++.dg/other/crash-9.C: New test.
2010-02-03 Jason Merrill <jason@redhat.com>
PR c++/40138
* g++.dg/ext/builtin11.C: New.
2010-02-03 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42944
* gcc.dg/errno-1.c: New testcase.
2010-02-03 Richard Guenther <rguenther@suse.de>
PR middle-end/42927
* gcc.c-torture/compile/pr42927.c: New testcase.
2010-01-29 Dodji Seketeli <dodji@redhat.com>
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* g++.dg/other/crash-5.C: New test.
* g++.dg/other/crash-7.C: New test.
* g++.dg/other/crash-8.C: New test.
2010-01-28 Uros Bizjak <ubizjak@gmail.com>
PR target/42891
* gcc.target/i386/pr42891.c: New test.
2010-01-28 Richard Guenther <rguenther@suse.de>
PR middle-end/42883
* g++.dg/torture/pr42883.C: New testcase.
2010-01-28 Michael Matz <matz@suse.de>
* gcc.target/i386/pr42881.c: New test.
2010-01-28 Dodji Seketeli <dodji@redhat.com>
PR c++/42713
PR c++/42820
* g++.dg/template/typedef27.C: New test case.
* g++.dg/template/typedef28.C: New test case.
2010-01-27 Jakub Jelinek <jakub@redhat.com>
PR middle-end/42874
* gcc.dg/vla-22.c: New test.
2010-01-26 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42250
* gcc.dg/pr42250.c: New testcase.
2010-01-25 Tobias Burnus <burnus@net-b.de>
PR fortran/42858
* gfortran.dg/generic_21.f90: New test.
2010-01-21 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/42585
* gcc.dg/tree-ssa/pr42585.c: New test.
2010-01-20 Alexandre Oliva <aoliva@redhat.com>
PR debug/42715
* gcc.dg/pr42715.c: New.
2010-01-20 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42717
* gcc.c-torture/compile/pr42717.c: New testcase.
2010-01-19 Paul Thomas <pault@gcc.gnu.org>
PR fortran/42783
* gfortran.dg/bounds_check_15.f90 : New test.
2010-01-18 Dodji Seketeli <dodji@redhat.com>
PR c++/42766
* g++.dg/conversion/op6.C: New test.
2010-01-18 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42781
* gfortran.fortran-torture/compile/pr42781.f90: New testcase.
2010-01-17 Richard Guenther <rguenther@suse.de>
PR middle-end/42248
* gcc.c-torture/execute/pr42248.c: New testcase.
2010-01-17 Janus Weil <janus@gcc.gnu.org>
PR fortran/42677
* gfortran.dg/interface_assignment_5.f90: New test.
2010-01-15 Richard Guenther <rguenther@suse.de>
PR middle-end/42739
* g++.dg/torture/pr42739.C: New testcase.
2010-01-14 Jerry DeLisle <jvdelisle@gcc.gnu.org>
PR fortran/42684
* gfortran.dg/interface_31.f90: New test.
2010-01-14 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/42706
* gcc.dg/ipa/pr42706.c: New testcase.
2010-01-14 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/42714
* g++.dg/torture/pr42714.C: New test.
2010-01-14 Alexander Monakov <amonakov@ispras.ru>
PR rtl-optimization/42388
* gcc.dg/pr42388.c: New.
2010-01-14 Alexander Monakov <amonakov@ispras.ru>
PR rtl-optimization/42294
* gfortran.dg/pr42294.f: New.
2010-01-14 Ira Rosen <irar@il.ibm.com>
PR tree-optimization/42709
* gcc.dg/vect/pr42709.c: New test.
2010-01-13 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42730
* gcc.c-torture/compile/pr42730.c: New testcase.
2010-01-13 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/42704
* g++.dg/torture/pr42704.C: New test.
2010-01-13 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/42703
* gcc.c-torture/compile/pr42703.c: New test.
2010-01-13 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42705
* gcc.c-torture/compile/pr42705.c: New testcase.
2010-01-13 Richard Guenther <rguenther@suse.de>
PR middle-end/42716
* gcc.c-torture/compile/pr42716.c: New testcase.
2010-01-12 Joseph Myers <joseph@codesourcery.com>
PR c/42708
* gcc.c-torture/compile/pr42708-1.c: New test.
2010-01-09 Alexandre Oliva <aoliva@redhat.com>
PR middle-end/42363
* gcc.dg/torture/pr42363.c: New.
2010-01-09 Alexandre Oliva <aoliva@redhat.com>
PR debug/42604
PR debug/42395
* gcc.dg/vect/pr42604.c: New.
* gcc.dg/vect/pr42395.c: New.
2010-01-09 Richard Guenther <rguenther@suse.de>
PR middle-end/42512
* gcc.c-torture/execute/pr42512.c: New testcase.
Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/conversion/op6.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/conversion/op6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ext/builtin11.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/ext/builtin11.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-5.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-7.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-7.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-8.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-8.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-9.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-9.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef27.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/template/typedef27.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef28.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/template/typedef28.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42704.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42704.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42714.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42714.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42739.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42739.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42883.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42883.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42703.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42703.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42705.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42705.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42716.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42716.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42717.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42717.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42730.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42730.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42927.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42927.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42248.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/execute/pr42248.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42512.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/execute/pr42512.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/errno-1.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/errno-1.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/ipa/pr42706.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/ipa/pr42706.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42250.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42250.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42388.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42388.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42715.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42715.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr42363.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/torture/pr42363.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42395.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42395.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42604.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42604.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42709.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42709.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vla-22.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/vla-22.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42881.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.target/i386/pr42881.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42891.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.target/i386/pr42891.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/bounds_check_15.f90
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/bounds_check_15.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/generic_21.f90
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/generic_21.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/interface_31.f90
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/interface_31.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/interface_assignment_5.f90
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/interface_assignment_5.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr42294.f
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/pr42294.f
branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (10 preceding siblings ...)
2010-01-08 17:55 ` sebpop at gmail dot com
@ 2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
2010-02-07 4:49 ` hjl at gcc dot gnu dot org
13 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-09 12:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from rguenth at gcc dot gnu dot org 2010-01-09 12:04 -------
Subject: Bug 42512
Author: rguenth
Date: Sat Jan 9 12:04:17 2010
New Revision: 155757
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155757
Log:
2010-01-09 Richard Guenther <rguenther@suse.de>
PR middle-end/42512
* tree-scalar-evolution.c (interpret_loop_phi): Make sure
the evolution is compatible with the initial condition.
* gcc.c-torture/execute/pr42512.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr42512.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-scalar-evolution.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (11 preceding siblings ...)
2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
@ 2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
2010-02-07 4:49 ` hjl at gcc dot gnu dot org
13 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-09 12:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from rguenth at gcc dot gnu dot org 2010-01-09 12:04 -------
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (9 preceding siblings ...)
2010-01-08 17:21 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 17:55 ` sebpop at gmail dot com
2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
` (2 subsequent siblings)
13 siblings, 0 replies; 16+ messages in thread
From: sebpop at gmail dot com @ 2010-01-08 17:55 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
------- Comment #11 from sebpop at gmail dot com 2010-01-08 17:55 -------
Subject: Re: [4.5 Regression] integer wrong code bug
with loop
> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
> Â 1ul for (unsigned long) { 1, +, 1 }_1
>
This is correct.
> and
>
> Â (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
> Â i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
>
> ? Â Can the latter two happen all?
Yes, these could happen, and you are right, we should see
the initial value of a chrec through the type conversion lenses.
> Is it even correct to talk about a
> general initial condition in this case? Â Consider
>
> Â { { 1, +, 1 }_2, +, 1 }_1
>
> initial_condition will return 1 for the chrec even though that is not
> correct because the initial condition is not constant in loop 1.
If you want, there is an initial condition for the loop_1 and that would be
{1, +, 1}_2, and there is an initial condition 1 for loop nest loop_2:
loop_2
i = loop_2_phi (0, i+1) = {1, +, 1}_2
loop_1
j = loop_1_phi (i, j+1) = {{1, +, 1}_2, +, 1}_1
> I suppose I'd only see that if instantiating the chrec at the point
> where I placed the fix? Â So I really only see at most a single outer
> conversion around the chrec?
Yes, I think that at most you can have only one conversion around a chrec.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2010-01-08 17:21 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 17:55 ` Sebastian Pop
0 siblings, 0 replies; 16+ messages in thread
From: Sebastian Pop @ 2010-01-08 17:55 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
> 1ul for (unsigned long) { 1, +, 1 }_1
>
This is correct.
> and
>
> (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
> i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
>
> ? Can the latter two happen all?
Yes, these could happen, and you are right, we should see
the initial value of a chrec through the type conversion lenses.
> Is it even correct to talk about a
> general initial condition in this case? Consider
>
> { { 1, +, 1 }_2, +, 1 }_1
>
> initial_condition will return 1 for the chrec even though that is not
> correct because the initial condition is not constant in loop 1.
If you want, there is an initial condition for the loop_1 and that would be
{1, +, 1}_2, and there is an initial condition 1 for loop nest loop_2:
loop_2
i = loop_2_phi (0, i+1) = {1, +, 1}_2
loop_1
j = loop_1_phi (i, j+1) = {{1, +, 1}_2, +, 1}_1
> I suppose I'd only see that if instantiating the chrec at the point
> where I placed the fix? So I really only see at most a single outer
> conversion around the chrec?
Yes, I think that at most you can have only one conversion around a chrec.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (8 preceding siblings ...)
2010-01-08 17:07 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 17:21 ` rguenth at gcc dot gnu dot org
2010-01-08 17:55 ` Sebastian Pop
2010-01-08 17:55 ` sebpop at gmail dot com
` (3 subsequent siblings)
13 siblings, 1 reply; 16+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-08 17:21 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-08 17:21 -------
Ok, I have that fixed locally at the place of the patch but I wonder if
initial_condition () shouldn't return for example
1ul for (unsigned long) { 1, +, 1 }_1
and
(int) i_2 for (int) { i_2, +, 1 }_1
and further (for short i_2)
i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
? Can the latter two happen all? Is it even correct to talk about a
general initial condition in this case? Consider
{ { 1, +, 1 }_2, +, 1 }_1
initial_condition will return 1 for the chrec even though that is not
correct because the initial condition is not constant in loop 1.
I suppose I'd only see that if instantiating the chrec at the point
where I placed the fix? So I really only see at most a single outer
conversion around the chrec?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (7 preceding siblings ...)
2010-01-08 16:53 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 17:07 ` rguenth at gcc dot gnu dot org
2010-01-08 17:21 ` rguenth at gcc dot gnu dot org
` (4 subsequent siblings)
13 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-08 17:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-08 17:07 -------
Ok, exactly the case I thought of (a conversion around the CHREC). I'll see to
fix that up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (6 preceding siblings ...)
2010-01-08 16:20 ` spop at gcc dot gnu dot org
@ 2010-01-08 16:53 ` rguenth at gcc dot gnu dot org
2010-01-08 17:07 ` rguenth at gcc dot gnu dot org
` (5 subsequent siblings)
13 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-08 16:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-08 16:53 -------
It FAILs
FAIL: gcc.dg/vect/pr36630.c scan-tree-dump-times vect "vectorized 1 loops" 1
but otherwise passes testing. I'll see what effect it has on SPEC 2006 and
investigate the above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (5 preceding siblings ...)
2010-01-08 15:00 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 16:20 ` spop at gcc dot gnu dot org
2010-01-08 16:53 ` rguenth at gcc dot gnu dot org
` (6 subsequent siblings)
13 siblings, 0 replies; 16+ messages in thread
From: spop at gcc dot gnu dot org @ 2010-01-08 16:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from spop at gcc dot gnu dot org 2010-01-08 16:20 -------
Subject: Re: [4.5 Regression] integer wrong code bug
with loop
I like the patch that you proposed in Comment #6.
Let's see if it passes bootstrap and test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (4 preceding siblings ...)
2010-01-08 14:07 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 15:00 ` rguenth at gcc dot gnu dot org
2010-01-08 16:20 ` spop at gcc dot gnu dot org
` (7 subsequent siblings)
13 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-08 15:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-08 15:00 -------
Hm, actually what is wrong is the evolution of l_2_18:
(scalar = l_2_18)
(scalar_evolution = {255, +, 0x0ffffffff}_1))
that of l_2_10 is correct:
(scalar = l_2_10)
(scalar_evolution = (unsigned int) {254, +, 255}_1))
<bb 3>:
# l_2_18 = PHI <l_2_10(4), 0x0ffffffff(2)>
# prephitmp.10_25 = PHI <g_3.2_7(4), pretmp.9_24(2)>
# ivtmp.19_37 = PHI <ivtmp.19_29(4), 255(2)>
D.1960_3 = (short unsigned int) l_2_18;
g_3.1_5 = (short unsigned int) prephitmp.10_25;
D.1963_6 = D.1960_3 | g_3.1_5;
g_3.2_7 = (short int) D.1963_6;
g_3_lsm.18_11 = g_3.2_7;
D.1965_8 = (unsigned char) l_2_18;
D.1966_9 = D.1965_8 + 255;
l_2_10 = (unsigned int) D.1966_9;
ivtmp.19_29 = ivtmp.19_37 - 1;
if (ivtmp.19_29 != 0)
goto <bb 4>;
else
goto <bb 5>;
<bb 4>:
goto <bb 3>;
Thus we need to verify we maintain the correct initial condition only?
Like for example with
Index: tree-scalar-evolution.c
===================================================================
--- tree-scalar-evolution.c (revision 155732)
+++ tree-scalar-evolution.c (working copy)
@@ -1642,6 +1642,15 @@ interpret_loop_phi (struct loop *loop, g
init_cond = analyze_initial_condition (loop_phi_node);
res = analyze_evolution_in_loop (loop_phi_node, init_cond);
+ /* Verify we maintained the correct initial condition throughout
+ possible conversions in the SSA chain. */
+ if (res != chrec_dont_know)
+ {
+ tree new_init = initial_condition (res);
+ if (!operand_equal_p (init_cond, new_init, 0))
+ return chrec_dont_know;
+ }
+
return res;
}
Maybe too strict in case the returned chrec is wrapped in a conversion
operation itself (no idea if that ever happens - at least initial_condition
doesn't seem to deal with that during recursion either).
I'm going to test that patch.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2009-12-26 20:00:19 |2010-01-08 15:00:44
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (3 preceding siblings ...)
2009-12-27 14:43 ` ebotcazou at gcc dot gnu dot org
@ 2010-01-08 14:07 ` rguenth at gcc dot gnu dot org
2010-01-08 15:00 ` rguenth at gcc dot gnu dot org
` (8 subsequent siblings)
13 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-08 14:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-08 14:07 -------
I believe we can only either allow truncations or widenings in following
SSA edges. Otherwise we miss that in
int l_2;
for (l_2 = -1; l_2 != 0; l_2 = (unsigned char)(l_2 - 1))
g_3 |= l_2;
the evolution is irregular in that the initial value is integer -1. That is
what happens - we compute the evolution of the result of (unsigned char)(l_2
-1)
as { 255, +, 255 }_1 but we may not use this evolution to derive that of
the value assigned to l_2, (int) { 255, +, 255 }_1 because we cannot represent
this. The correct evolution is -1, 254, 253 ..., 0 which isn't representable.
Thus I think we need to either kill the conversion code completely or
at least severely restrict it with sth like
Index: gcc/tree-scalar-evolution.c
===================================================================
--- gcc/tree-scalar-evolution.c (revision 155732)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -1161,9 +1161,19 @@ follow_ssa_edge_expr (struct loop *loop,
{
CASE_CONVERT:
/* This assignment is under the form "a_1 = (cast) rhs. */
- res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
- halting_phi, evolution_of_loop, limit);
- *evolution_of_loop = chrec_convert (type, *evolution_of_loop, at_stmt);
+ rhs0 = TREE_OPERAND (expr, 0);
+ if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (rhs0))
+ || TREE_CODE (*evolution_of_loop) != POLYNOMIAL_CHREC)
+ {
+ res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
+ halting_phi, evolution_of_loop, limit);
+ *evolution_of_loop = chrec_convert (type, *evolution_of_loop,
at_stmt);
+ }
+ else
+ {
+ *evolution_of_loop = chrec_dont_know;
+ res = t_false;
+ }
break;
case INTEGER_CST:
@@ -1219,14 +1229,25 @@ follow_ssa_edge_in_rhs (struct loop *loo
enum tree_code code = gimple_assign_rhs_code (stmt);
tree type = gimple_expr_type (stmt), rhs1, rhs2;
t_bool res;
+ tree name;
switch (code)
{
CASE_CONVERT:
/* This assignment is under the form "a_1 = (cast) rhs. */
- res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
- halting_phi, evolution_of_loop, limit);
- *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt);
+ name = gimple_assign_rhs1 (stmt);
+ if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (name))
+ || TREE_CODE (*evolution_of_loop) != POLYNOMIAL_CHREC)
+ {
+ res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
+ halting_phi, evolution_of_loop, limit);
+ *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt);
+ }
+ else
+ {
+ *evolution_of_loop = chrec_dont_know;
+ res = t_false;
+ }
break;
case POINTER_PLUS_EXPR:
@@ -1759,7 +1780,11 @@ interpret_rhs_expr (struct loop *loop, g
CASE_CONVERT:
chrec1 = analyze_scalar_evolution (loop, rhs1);
- res = chrec_convert (type, chrec1, at_stmt);
+ if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (rhs1))
+ || TREE_CODE (chrec1) != POLYNOMIAL_CHREC)
+ res = chrec_convert (type, chrec1, at_stmt);
+ else
+ res = chrec_dont_know;
break;
default:
Sebastian - any better idea? This will at least regress
FAIL: gcc.dg/tree-ssa/scev-cast.c scan-tree-dump-times optimized "= \(unsigned
char\)" 1
FAIL: gcc.dg/tree-ssa/scev-cast.c scan-tree-dump-times optimized "= \(char\)" 1
because we cannot distinguish the really critical cases from ok ones.
The patch in comment #4 just makes the issue latent again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (2 preceding siblings ...)
2009-12-26 22:16 ` hjl dot tools at gmail dot com
@ 2009-12-27 14:43 ` ebotcazou at gcc dot gnu dot org
2010-01-08 14:07 ` rguenth at gcc dot gnu dot org
` (9 subsequent siblings)
13 siblings, 0 replies; 16+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2009-12-27 14:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-12-27 14:43 -------
> It may be caused by revision 147716:
>
> http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00693.html
Same trigger as the other so the same partial reversion works:
Index: tree-scalar-evolution.c
===================================================================
--- tree-scalar-evolution.c (revision 155361)
+++ tree-scalar-evolution.c (working copy)
@@ -1159,7 +1159,7 @@ follow_ssa_edge_expr (struct loop *loop,
switch (code)
{
- CASE_CONVERT:
+ case NOP_EXPR:
/* This assignment is under the form "a_1 = (cast) rhs. */
res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
halting_phi, evolution_of_loop, limit);
@@ -1222,7 +1222,7 @@ follow_ssa_edge_in_rhs (struct loop *loo
switch (code)
{
- CASE_CONVERT:
+ case NOP_EXPR:
/* This assignment is under the form "a_1 = (cast) rhs. */
res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
halting_phi, evolution_of_loop, limit);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
2009-12-26 20:00 ` [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop jakub at gcc dot gnu dot org
2009-12-26 22:13 ` hjl dot tools at gmail dot com
@ 2009-12-26 22:16 ` hjl dot tools at gmail dot com
2009-12-27 14:43 ` ebotcazou at gcc dot gnu dot org
` (10 subsequent siblings)
13 siblings, 0 replies; 16+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-12-26 22:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from hjl dot tools at gmail dot com 2009-12-26 22:16 -------
It is related to PR 41497.
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |spop at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
2009-12-26 20:00 ` [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop jakub at gcc dot gnu dot org
@ 2009-12-26 22:13 ` hjl dot tools at gmail dot com
2009-12-26 22:16 ` hjl dot tools at gmail dot com
` (11 subsequent siblings)
13 siblings, 0 replies; 16+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-12-26 22:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from hjl dot tools at gmail dot com 2009-12-26 22:13 -------
It may be caused by revision 147716:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00693.html
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ebotcazou at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
@ 2009-12-26 20:00 ` jakub at gcc dot gnu dot org
2009-12-26 22:13 ` hjl dot tools at gmail dot com
` (12 subsequent siblings)
13 siblings, 0 replies; 16+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-12-26 20:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from jakub at gcc dot gnu dot org 2009-12-26 20:00 -------
This breaks during ivopts.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priority|P3 |P1
Last reconfirmed|0000-00-00 00:00:00 |2009-12-26 20:00:19
date| |
Summary|integer wrong code bug with |[4.5 Regression] integer
|loop |wrong code bug with loop
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2022-10-25 11:40 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-42512-4@http.gcc.gnu.org/bugzilla/>
2022-10-25 11:40 ` [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop cvs-commit at gcc dot gnu.org
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
2009-12-26 20:00 ` [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop jakub at gcc dot gnu dot org
2009-12-26 22:13 ` hjl dot tools at gmail dot com
2009-12-26 22:16 ` hjl dot tools at gmail dot com
2009-12-27 14:43 ` ebotcazou at gcc dot gnu dot org
2010-01-08 14:07 ` rguenth at gcc dot gnu dot org
2010-01-08 15:00 ` rguenth at gcc dot gnu dot org
2010-01-08 16:20 ` spop at gcc dot gnu dot org
2010-01-08 16:53 ` rguenth at gcc dot gnu dot org
2010-01-08 17:07 ` rguenth at gcc dot gnu dot org
2010-01-08 17:21 ` rguenth at gcc dot gnu dot org
2010-01-08 17:55 ` Sebastian Pop
2010-01-08 17:55 ` sebpop at gmail dot com
2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
2010-02-07 4:49 ` hjl at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).