[Bug fortran/16206] rejects valid array initialization expression
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #13 from patchapp at dberlin dot org 2006-06-29 21:35 --- Subject: Bug number PR16206 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00911.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #12 from pault at gcc dot gnu dot org 2006-06-23 15:41 --- Fixed on trunk and 4.1 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=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #11 from pault at gcc dot gnu dot org 2006-06-23 04:47 --- Subject: Bug 16206 Author: pault Date: Fri Jun 23 04:46:50 2006 New Revision: 114925 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114925 Log: 2006-06-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25049 PR fortran/25050 * check.c (non_init_transformational): New function. (find_substring_ref): New function to signal use of disallowed transformational intrinsic in an initialization expression. (gfc_check_all_any): Call previous if initialization expr. (gfc_check_count): The same. (gfc_check_cshift): The same. (gfc_check_dot_product): The same. (gfc_check_eoshift): The same. (gfc_check_minloc_maxloc): The same. (gfc_check_minval_maxval): The same. (gfc_check_gfc_check_product_sum): The same. (gfc_check_pack): The same. (gfc_check_spread): The same. (gfc_check_transpose): The same. (gfc_check_unpack): The same. PR fortran/18769 *intrinsic.c (add_functions): Add gfc_simplify_transfer. *intrinsic.h : Add prototype for gfc_simplify_transfer. *simplify.c (gfc_simplify_transfer) : New function to act as placeholder for eventual implementation. Emit error for now. PR fortran/16206 * expr.c (find_array_element): Eliminate condition on length of offset. Add bounds checking. Rearrange exit. Return try and put gfc_constructor result as an argument. (find_array_section): New function. (find_substring_ref): New function. (simplify_const_ref): Add calls to previous. (simplify_parameter_variable): Return on NULL expr. (gfc_simplify_expr): Only call gfc_expand_constructor for full arrays. PR fortran/20876 * match.c (gfc_match_forall): Add missing locus to gfc_code. 2006-06-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16206 * gfortran.dg/array_initializer_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_initializer_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.h branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/simplify.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #10 from pault at gcc dot gnu dot org 2006-06-20 04:31 --- Subject: Bug 16206 Author: pault Date: Tue Jun 20 04:30:48 2006 New Revision: 114802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114802 Log: 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25049 PR fortran/25050 * check.c (non_init_transformational): New function. (find_substring_ref): New function to signal use of disallowed transformational intrinsic in an initialization expression. (gfc_check_all_any): Call previous if initialization expr. (gfc_check_count): The same. (gfc_check_cshift): The same. (gfc_check_dot_product): The same. (gfc_check_eoshift): The same. (gfc_check_minloc_maxloc): The same. (gfc_check_minval_maxval): The same. (gfc_check_gfc_check_product_sum): The same. (gfc_check_pack): The same. (gfc_check_spread): The same. (gfc_check_transpose): The same. (gfc_check_unpack): The same. PR fortran/18769 *intrinsic.c (add_functions): Add gfc_simplify_transfer. *intrinsic.h : Add prototype for gfc_simplify_transfer. *simplify.c (gfc_simplify_transfer) : New function to act as placeholder for eventual implementation. Emit error for now. PR fortran/16206 * expr.c (find_array_element): Eliminate condition on length of offset. Add bounds checking. Rearrange exit. Return try and put gfc_constructor result as an argument. (find_array_section): New function. (find_substring_ref): New function. (simplify_const_ref): Add calls to previous. (simplify_parameter_variable): Return on NULL expr. (gfc_simplify_expr): Only call gfc_expand_constructor for full arrays. PR fortran/20876 * match.c (gfc_match_forall): Add missing locus to gfc_code. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28005 * m4/matmul.m4: aystride = 1 does not uniquely detect the presence of a temporary transpose; an array element in the first dimension produces the same signature. Detect this using the rank of a and add specific code. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-06-20 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16206 * gfortran.dg/array_initializer_1.f90: New test. PR fortran/28005 * gfortran.dg/matmul_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_initializer_1.f90 trunk/gcc/testsuite/gfortran.dg/matmul_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/match.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #9 from paulthomas2 at wanadoo dot fr 2006-06-16 16:18 --- Subject: Re: rejects valid array initialization expression Harald, >You might wish to extend this to m(5) = ..., because: > > > >> integer, parameter :: p(8) = (/(m(i:i+1), i = 1,4)/) >> >> > >the last accessed element is m(5). > > This lost me a couple of evenings because it kept segfaulting on the out-of bounds reference! I thought that it was something wrong with the logic of the patch. *groan*. I have put bounds checking in there now and will likely submit tomorrow or Sunday morning. gfortran now does more with initializers than any other compiler that I can lay hands on. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #8 from anlauf at gmx dot de 2006-06-16 08:23 --- (In reply to comment #7) Paul, thanks for looking into this! > program gfortran_bug2 [...] > integer, parameter :: m(4) = (/1,2,3,4/) You might wish to extend this to m(5) = ..., because: > integer, parameter :: p(8) = (/(m(i:i+1), i = 1,4)/) the last accessed element is m(5). Cheers, -ha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #7 from pault at gcc dot gnu dot org 2006-06-15 17:39 --- Created an attachment (id=11675) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11675&action=view) A near submission level patch for the PR I have not marked the previous version as obsolete because it could well be a valuable chunk of a future patch. The attached fixes most of the cases below, except for the last. Array sections, with variable index expressions, in implicit do loops still give an error; in fact the same error as g95! I think I can see how to do that final tweek Paul PS Please excuse the state of these "working" test programs; I use them as labs to test and diagnose the patch. program gfortran_bug1 ! real, parameter :: x(4,4) = reshape((/(i, i = 1, 16)/), (/4,4/)) real, parameter :: xx(2) = (/ 12.0, 14.0 /) real, parameter :: xxx(2) = (/ xx - 3 /) character(4), parameter :: chr(4) = (/"abcd", "efgh", "ijkl", "mnop"/), & scalar = "abcd" character(4), parameter :: scalar2 = chr(1)(2:4) ,chrt(2) = (/chr(2:2)(2:3), chr(3:3)(3:4)/) character(2), parameter :: chrr(2) = chr(2:3)(2:3) character(2), parameter :: chrx(2) = (/(chr(i)(2:3), i=2,3)/) ! ! gfortran dies at the following, which AFAICT is legal: ! real, parameter :: y(4) = (/ x(1:2, 2), x(1:2, 4)/) real, parameter :: z(2) = x(1:2, 1) + 1 print *, x print *, z print *, y print *, xxx print *, chrr print *, chrt print *, scalar2 print *, chrx end program gfortran_bug1 program gfortran_bug2 ! ! character(4), parameter :: chr(4) = (/"abcd", "efgh", "ijkl", "mnop"/), & ! scalar = "abcd" ! character(4), parameter :: chrx(2) = (/(chr(i), i=2,3)/) integer, parameter :: m(4) = (/1,2,3,4/) integer, parameter :: n(2) = (/(m(i), i = 2,3)/) integer, parameter :: o(4) = (/(n, i = 2,3)/) integer, parameter :: q(4) = (/((/(m(j), j = i, i+1)/), i = 2,3)/) integer, parameter :: p(8) = (/(m(i:i+1), i = 1,4)/) ! print *, chrx print *, n, o, p end program gfortran_bug2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-09 19:40 --- I seem to be on the way to fixing this, so I had beter assign it to myself! 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-06-09 15:19 --- Created an attachment (id=11647) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11647&action=view) An experimental fix for the PR This was to have been the second of the two approaches, described above. It works, in that it fixes the bug but its limitations become obvious, very quickly; try some arithmetic with an arrya_section, for example. However, all is not lost! You will note the heavy use of gmp to do the arithmetic - that was in preparation for a tactical retreat to approach (i). I have done all the tests to understand what happens in expr.c and am confident that I will have a proper fix in about 1 week. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-06-06 11:46 --- (In reply to comment #3) > This bug report is approaching its second anniversary. > Does anybody still watch it or take care? Yes, Harald. I have been looking these last days at a number of array initializer problems. I have not entirely decided how to do this one yet: (i) Blasting through and expanding the array setion is one way; or (ii) Doing as Erik Edelmann suggested in another PR; use a normal assignment for the initialization and a static flag to make sure that it only is done once. The first is consistent with the existing structure and the second can be used to simplify a lot but will be much more work. This is why I am looking at initializer PRs as a package. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #3 from anlauf at gmx dot de 2006-05-29 21:22 --- This bug report is approaching its second anniversary. Does anybody still watch it or take care? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
