[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #16 from tkoenig at gcc dot gnu dot org 2008-11-23 15:10 --- Subject: Bug 38135 Author: tkoenig Date: Sun Nov 23 15:08:32 2008 New Revision: 142134 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142134 Log: 2008-11-23 Thomas Koenig [EMAIL PROTECTED] PR libfortran/38135 Backport from trunk. * m4/reshape.m4: Tread PAD as if it were SOURCE when SOURCE is empty. * intrinsics/reshape_generic.c: Likewise. * generated/reshape_c10.c Regenerated. * generated/reshape_c16.c Regenerated. * generated/reshape_c4.c Regenerated. * generated/reshape_c8.c Regenerated. * generated/reshape_i16.c Regenerated. * generated/reshape_i4.c Regenerated. * generated/reshape_i8.c Regenerated. * generated/reshape_r10.c Regenerated. * generated/reshape_r16.c Regenerated. * generated/reshape_r4.c Regenerated. * generated/reshape_r8.c Regenerated. 2008-11-23 Thomas Koenig [EMAIL PROTECTED] PR libfortran/38135 Backport from trunk. * gfortran.dg/reshape_pad_1.f90: New test case. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/reshape_pad_1.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/generated/reshape_c10.c branches/gcc-4_3-branch/libgfortran/generated/reshape_c16.c branches/gcc-4_3-branch/libgfortran/generated/reshape_c4.c branches/gcc-4_3-branch/libgfortran/generated/reshape_c8.c branches/gcc-4_3-branch/libgfortran/generated/reshape_i16.c branches/gcc-4_3-branch/libgfortran/generated/reshape_i4.c branches/gcc-4_3-branch/libgfortran/generated/reshape_i8.c branches/gcc-4_3-branch/libgfortran/generated/reshape_r10.c branches/gcc-4_3-branch/libgfortran/generated/reshape_r16.c branches/gcc-4_3-branch/libgfortran/generated/reshape_r4.c branches/gcc-4_3-branch/libgfortran/generated/reshape_r8.c branches/gcc-4_3-branch/libgfortran/intrinsics/reshape_generic.c branches/gcc-4_3-branch/libgfortran/m4/reshape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #17 from tkoenig at gcc dot gnu dot org 2008-11-23 15:10 --- Fixed on 4.3. Closing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #18 from tkoenig at gcc dot gnu dot org 2008-11-23 15:17 --- ... and now really closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #14 from tkoenig at gcc dot gnu dot org 2008-11-19 19:33 --- The problem is fixed on trunk, I think we can close this after backporting. Mikael, if you think the problem you mentioned in comment #4 warrants its own PR, maybe you could open it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #15 from mikael at gcc dot gnu dot org 2008-11-19 20:56 --- (In reply to comment #14) Mikael, if you think the problem you mentioned in comment #4 warrants its own PR, maybe you could open it. PR 38184 opened for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #13 from tkoenig at gcc dot gnu dot org 2008-11-18 22:44 --- Subject: Bug 38135 Author: tkoenig Date: Tue Nov 18 22:43:05 2008 New Revision: 141982 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141982 Log: 2008-11-18 Thomas Koenig [EMAIL PROTECTED] PR libfortran/38135 * m4/reshape.m4: Correct bounds checking when PAD is present. Treat PAD as if it were SOURCE when SOURCE is empty. * intrinsics/reshape_generic.c: Likewise. * generated/reshape_c10.c Regenerated. * generated/reshape_c16.c Regenerated. * generated/reshape_c4.c Regenerated. * generated/reshape_c8.c Regenerated. * generated/reshape_i16.c Regenerated. * generated/reshape_i4.c Regenerated. * generated/reshape_i8.c Regenerated. * generated/reshape_r10.c Regenerated. * generated/reshape_r16.c Regenerated. * generated/reshape_r4.c Regenerated. * generated/reshape_r8.c Regenerated. 2008-11-18 Thomas Koenig [EMAIL PROTECTED] PR libfortran/38135 * gfortran.dg/reshape_pad_1.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/reshape_pad_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/reshape_c10.c trunk/libgfortran/generated/reshape_c16.c trunk/libgfortran/generated/reshape_c4.c trunk/libgfortran/generated/reshape_c8.c trunk/libgfortran/generated/reshape_i16.c trunk/libgfortran/generated/reshape_i4.c trunk/libgfortran/generated/reshape_i8.c trunk/libgfortran/generated/reshape_r10.c trunk/libgfortran/generated/reshape_r16.c trunk/libgfortran/generated/reshape_r4.c trunk/libgfortran/generated/reshape_r8.c trunk/libgfortran/intrinsics/reshape_generic.c trunk/libgfortran/m4/reshape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-11-16 09:04 --- Simplified test case (without the second reshape): The problem appears to be the empty SOURCE with the presence of PAD. $ cat bar.f90 program main integer, parameter :: N = 3 integer :: A(N,N) integer :: b(n+1) b = (/ 1, 2, 2, 2 /) A(1:N,1:N)=reshape(A(1:0,1),(/N,N/),b) write(*,'(3i5)') A end program main $ gfortran bar.f90 $ ./a.out 1*1 *1* 1*1 -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-16 09:04:10 date|| Summary|FORALL gives wrong result |RESHAPE gives wrong result http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-16 11:38 --- (In reply to comment #3) The problem appears to be the empty SOURCE with the presence of PAD. I agree. There are two bugs actually: (1) the front-end doesn't expand the reshape. (at least in this case: reshape([integer::],[N,N],[1,2,2,2]) ) (2) reshape gives wrong results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #5 from mikael at gcc dot gnu dot org 2008-11-16 13:45 --- Index: simplify.c === --- simplify.c (révision 141833) +++ simplify.c (copie de travail) @@ -3410,9 +3410,6 @@ is_constant_array_expr (gfc_expr *e) if (e-expr_type != EXPR_ARRAY || !gfc_is_constant_expr (e)) return false; - if (e-value.constructor == NULL) -return false; - for (c = e-value.constructor; c; c = c-next) if (c-expr-expr_type != EXPR_CONSTANT) return false; This solves (1) (the original testcase), but not (2). I will regtest it. for (2), I'm puzzled. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-11-16 13:58 --- (In reply to comment #5) for (2), I'm puzzled. :( I'm onto it; the problems are in reshape.m4 / reshape_generic.c . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #7 from mikael at gcc dot gnu dot org 2008-11-16 15:22 --- (In reply to comment #6) I'm onto it; the problems are in reshape.m4 / reshape_generic.c . Ok, leaving it to you. According to my tests, sstride0 has suspicious values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-11-16 16:03 --- Created an attachment (id=16700) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16700action=view) Patch for the library part Well, here's a patch for the library part. Apparently, nobody ever paid much attention to the pad argument before (a few things were just plain wrong there). Mikael, you were right about sstride0, but that wasn't the only problem :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #9 from mikael at gcc dot gnu dot org 2008-11-16 18:46 ---
(In reply to comment #8)
Are you sure this is needed ?
if (sempty)
{
- /* Switch immediately to the pad array. */
+ /* Pretend we are using the pad array the first time around, too. */
src = pptr;
- sptr = NULL;
+ sptr = pptr;
sdim = pdim;
for (dim = 0; dim pdim; dim++)
sptr is only used later to switch from source to pad, which is not needed here
as we start with pad directly. No?
Mikael, you were right about sstride0, but that wasn't the only problem :-)
While we are at it, we could calculate sstride0 outside the loop, that would be
5ns faster ;-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #10 from mikael at gcc dot gnu dot org 2008-11-16 19:44 --- (In reply to comment #9) Those are only details, it works nicely :-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-11-16 20:38 --- Regression-test and full patch, including test cases, tomorrow. RL keeps interfering :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #12 from pault at gcc dot gnu dot org 2008-11-16 22:25 --- Thomas, Since you are there, bar the shouting, I thought that I would assign you:-) Cheers and thanks Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
