--- Comment #6 from spop at gcc dot gnu dot org 2009-11-03 05:57 ---
Fixed in the graphite branch as explained above.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from spop at gcc dot gnu dot org 2009-10-23 20:52 ---
The data dependence analysis is not instructed that the iteration
domain of the k loop will be splitted, and thus it answers
"interchanging stmt_5 is a correct transform".
To correct this problem we have to distribute
--- Comment #4 from sebpop at gmail dot com 2009-10-23 19:54 ---
Subject: Re: graphite miscompiles 454.calculix
of the SPEC 2k6
On Fri, Oct 23, 2009 at 14:46, spop at gcc dot gnu dot org
wrote:
> and the code generated by CLooG for the interchange looks like this:
>
> for (sc
On Fri, Oct 23, 2009 at 14:46, spop at gcc dot gnu dot org
wrote:
> and the code generated by CLooG for the interchange looks like this:
>
> for (scat_1=0;scat_1<=2;scat_1++) {
> for (scat_3=0;scat_3<=2;scat_3++) {
> S4(scat_1,scat_3) ;
> for (scat_5=0;scat_5<=2;scat_5++) {
> S5(scat_1
--- Comment #3 from spop at gcc dot gnu dot org 2009-10-23 19:46 ---
Also with -O3 the code of the loop body looks much nicer: several statements
disappear as they do not contain code anymore: so we have this LST
transformed_lst (
(root
0 (loop
0 (loop
0 stmt_4
1 (lo
--- Comment #2 from spop at gcc dot gnu dot org 2009-10-23 19:43 ---
With -fno-loop-interchange the code generated is correct but strange as the
statement
S8(scat_1,scat_3) ;
does iterate one less time than the other statements of loop scat_3.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #1 from spop at gcc dot gnu dot org 2009-10-23 18:16 ---
The bug disappears with disabling the loop interchange, but the code
generated by CLooG still looks strange:
for (scat_1=0;scat_1<=2;scat_1++) {
S3(scat_1) ;
for (scat_3=0;scat_3<=1;scat_3++) {
S4(scat_1,scat_3
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last recon
