[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-29 08:11 --- Subject: Bug 35698 Author: pault Date: Sat Mar 29 08:11:02 2008 New Revision: 133710 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133710 Log: 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * trans-array.c (gfc_array_init_size): Set 'size' zero if negative in one dimension. PR fortran/35702 * trans-expr.c (gfc_trans_string_copy): Only assign a char directly if the lhs and rhs types are the same. 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * gfortran.dg/allocate_zerosize_3.f: New test. PR fortran/35702 * gfortran.dg/character_assign_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_zerosize_3.f trunk/gcc/testsuite/gfortran.dg/character_assign_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-29 08:18 --- Subject: Bug 35698 Author: pault Date: Sat Mar 29 08:17:36 2008 New Revision: 133711 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133711 Log: 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * trans-array.c (gfc_array_init_size): Set 'size' zero if negative in one dimension. PR fortran/35702 * trans-expr.c (gfc_trans_string_copy): Only assign a char directly if the lhs and rhs types are the same. 2008-03-29 Paul Thomas [EMAIL PROTECTED] PR fortran/35698 * gfortran.dg/allocate_zerosize_3.f: New test. PR fortran/35702 * gfortran.dg/character_assign_1.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/allocate_zerosize_3.f branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/character_assign_1.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/trans-array.c branches/gcc-4_3-branch/gcc/fortran/trans-expr.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-29 08:19 --- Fixed on trunk and 4.3 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #4 from pault at gcc dot gnu dot org 2008-03-28 08:33 --- (In reply to comment #3) 1) If I am not mistaken, the first change is within a commented block (look at the last line in the diff.: ' } */') Yes, indeed - the comment has been made consistent with the intended patch 2) With the patch I have a lot of regressions on my quick and dirty testsuite. Among them I have several: The patch posted here is in error - the version posted to the lists is correct. Please note that I have no idea why what appears here did anything for the reporter's testcase! + size = fold_build3 (COND_EXPR, gfc_array_index_type, cond, + size, gfc_index_zero_node); has the last two arguments the wrong way round *sorry* Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #3 from dominiq at lps dot ens dot fr 2008-03-27 11:08 --- Some comments about the patch in comment #2: 1) If I am not mistaken, the first change is within a commented block (look at the last line in the diff.: ' } */') 2) With the patch I have a lot of regressions on my quick and dirty testsuite. Among them I have several: test.exe(65765) malloc: *** error for object 0x2004c0: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug one example being: PROGRAM testb IMPLICIT none CHARACTER(len=120), DIMENSION(3) :: vect CHARACTER(len=1), DIMENSION(:), ALLOCATABLE :: cvect INTEGER :: length !!$--- vect(:)=(/'ippaaa0','ippaaa1','ippaaa2'/) WRITE(*,*) 'Say hi!' length=SIZE(TRANSFER(vect,cvect)) WRITE(*,*) 'Say hi again!', length ALLOCATE(cvect(length)) cvect=TRANSFER(vect,cvect) !!$- END PROGRAM testb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #2 from pault at gcc dot gnu dot org 2008-03-26 22:20 --- This one is relatively easy: Index: gcc/fortran/trans-array.c === *** gcc/fortran/trans-array.c (revision 133278) --- gcc/fortran/trans-array.c (working copy) *** gfc_conv_loop_setup (gfc_loopinfo * loop *** 3506,3512 a.ubound[n] = specified_upper_bound; a.stride[n] = stride; size = ubound + size; //size = ubound + 1 - lbound ! stride = stride * size; } return (stride); } */ --- 3516,3522 a.ubound[n] = specified_upper_bound; a.stride[n] = stride; size = ubound + size; //size = ubound + 1 - lbound ! stride = size = 0 ? stride * size : 0; } return (stride); } */ *** gfc_array_init_size (tree descriptor, in *** 3605,3610 --- 3615,3623 else or_expr = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, or_expr, cond); + size = fold_build3 (COND_EXPR, gfc_array_index_type, cond, + size, gfc_index_zero_node); + /* Multiply the stride by the number of elements in this dimension. */ stride = fold_build2 (MULT_EXPR, gfc_array_index_type, stride, size); stride = gfc_evaluate_now (stride, pblock); I'll put it on to regtest. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-25 23:52:07 |2008-03-26 22:20:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-25 23:52 --- Thanks for testing/reducing/reporting this. If one looks at the bounds, one sees that for negative lower bounds the output is wrong. NAG correctly has: 2 1 0 1 -2 -3 -4 3 4 5 0 7 8 9 while gfortran wrongly has: 2 1 0 1 1 1 1 3 4 5 0 0 0 0 ila1[S.2 + -1] = lla.dim[S.2 + -1].stride = 0 lla.dim[S.2 + -1].ubound = lla.dim[S.2 + -1].lbound || lla.dim[S.2 + -1].stride 0 lla.dim[S.2 + -1].ubound = lla.dim[S.2 + -1].lbound ? (integer(kind=4)) lla.dim[S.2 + -1].lbound : 1; This looks ok. However, I do not understand the stride calculation: lla.dim[3].lbound = (integer(kind=8)) nf10; lla.dim[3].ubound = 1; lla.dim[3].stride = 48; so far so good, but why the following? D.950 = (2 - (integer(kind=8)) nf10) * 48; lla.dim[4].lbound = -2; lla.dim[4].ubound = 7; lla.dim[4].stride = D.950; D.950 is (2-10)*48 = -384 ?!?!? -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-03-25 23:52:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
