[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-07-06 06:00 --- Regardless, we should catch this and issue the error message about -fmax-array-constructor. I don't see why we would want to do anything else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #12 from ohl at physik dot uni-wuerzburg dot de 2010-07-06 07:38 --- (In reply to comment #10) It is not particularly efficient to use a huge static variable. [...] initialization at run time is the better choice for large arrays. The best solution for PARAMETER depends on the purpose. In the real-life application, the non-trivial PARAMETER values are computed by an external code generator to match the code and its impossible to compute them in Fortran at runtime. It would be possible to read the values from a separate file generated together with the code, but it's tedious and introduces another failure mode. However, I cannot see that this would be more efficient than loading the equivalent data sections. Furthermore, declaring the data as PARAMETER helps the optimizer and OpenMP, doesn't it? -- ohl at physik dot uni-wuerzburg dot de changed: What|Removed |Added CC||ohl at physik dot uni- ||wuerzburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #13 from burnus at gcc dot gnu dot org 2010-07-06 09:46 --- (In reply to comment #11) Regardless, we should catch this and issue the error message about -fmax-array-constructor. I don't see why we would want to do anything else. I concur. Juergen, does your program work with a sufficiently large -fmax-array-constructor=... ? (In reply to comment #12) It is not particularly efficient to use a huge static variable. [...] [...] initialization at run time is the better choice for large arrays. The best solution for PARAMETER depends on the purpose. In the real-life application, the non-trivial PARAMETER values are computed by an external code generator to match the code and its impossible to compute them in Fortran at runtime. As written: The best solution depends on the purpose. If the array (either static or parameter) gets very large, one has to think whether one should do something else. The answer might well be no. It would be possible to read the values from a separate file generated together with the code, but it's tedious and introduces another failure mode. However, I cannot see that this would be more efficient than loading the equivalent data sections. Furthermore, declaring the data as PARAMETER helps the optimizer and OpenMP, doesn't it? It depends. PARAMETERs - as currently implemented in gfortran - are spurious objects; they only materialize when used. Thus, when doing a = sin(PI), where PI is a parameter, gfortran replaces this by a= sin(value_of_PI) which can then be optimized. Similarly, if you have a large array and use, e.g. sum(large_PARAMETER) then the argument is reduced at compile time. However, if you do all the time a = large_PARAMETER_array(:,1) etc., a static temporary array is created to which the values are assigned to. Thus, the data might be present several times in the binary. It still helps with optimizations as the middle end know those values. Which variant is then faster at the end, it difficult to tell - in many cases the PARAMETER one. (Obvious disadvantages are: longer compile time, large .mod files, large binary files; for number crunching, those disadvantages are usually not that important.) Thus as written above: I would recommend to think of avoiding large static (SAVE) arrays (especially if initialized by a non-zero value) -- and at least quickly consider whether avoiding large PARAMETER arrays makes sense - but in both cases one can often make the conscious decision that using a static/parameter arrays is best. In your case it seems as if using a PARAMETER is most suitable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #14 from burnus at gcc dot gnu dot org 2010-07-06 14:57 --- Created an attachment (id=21107) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21107action=view) Draft patch -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #15 from burnus at gcc dot gnu dot org 2010-07-06 20:56 --- Subject: Bug 44742 Author: burnus Date: Tue Jul 6 20:56:07 2010 New Revision: 161888 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161888 Log: 2010-07-06 Tobias Burnus bur...@net-b.de PR fortran/44742 * array.c (gfc_expand_constructor): Add optional diagnostic. * gfortran.h (gfc_expand_constructor): Update prototype. * expr.c (gfc_simplify_expr, check_init_expr, gfc_reduce_init_expr): Update gfc_expand_constructor call. * resolve.c (gfc_resolve_expr): Ditto. 2010-07-06 Tobias Burnus bur...@net-b.de PR fortran/44742 * gfortran.dg/parameter_array_init_6.f90: New. * gfortran.dg/initialization_20.f90: Update dg-error. * gfortran.dg/initialization_24.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_init_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/initialization_20.f90 trunk/gcc/testsuite/gfortran.dg/initialization_24.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #16 from burnus at gcc dot gnu dot org 2010-07-06 20:59 --- FIXED on the trunk (4.6). Thanks for the bugreport. (The fix is to print an error if the constructor is too large; the error message points to -fmax-array-constructor=n which can be used to modify the limit.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #5 from reuter at physik dot uni-freiburg dot de 2010-07-05 17:41 --- Created an attachment (id=21095) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21095action=view) Code triggering the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #6 from reuter at physik dot uni-freiburg dot de 2010-07-05 17:44 --- I isolated the bug further and prepared a roughly 1 MB sniplet which triggers the ICE. It seems that the definition of the more than 500 logical array and packing them in one big array constructor is not well swallowed by gfortran. The bug appears in 4.5.0 (release) as well as 4.6.0 trunk revision 161046. 4.4.5 I didn't test but as you have the code now its trivial for you to verify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #7 from janus at gcc dot gnu dot org 2010-07-05 17:49 --- (In reply to comment #6) The bug appears in 4.5.0 (release) as well as 4.6.0 trunk revision 161046. 4.4.5 I didn't test but as you have the code now its trivial for you to verify. I get the same ICE also with 4.3 and 4.4 (with slightly differing line numbers, of course). -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-05 17:49:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #8 from janus at gcc dot gnu dot org 2010-07-05 18:49 --- (In reply to comment #6) I isolated the bug further and prepared a roughly 1 MB sniplet which triggers the ICE. Here is a reduced test case: module proc8 implicit none private integer, parameter :: n_cflow = 128 integer, parameter :: n_flv = 512 logical, dimension(n_flv), parameter, private :: a0001 = .false. logical, dimension(n_flv, n_cflow), parameter :: flv_col_is_allowed = reshape ( (/ a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001, a0001 /), (/ n_flv, n_cflow /) ) end module proc8 It works when using numbers smaller than 128*512=2^16. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #9 from janus at gcc dot gnu dot org 2010-07-05 21:02 --- Even shorter: module proc8 implicit none integer, parameter :: N = 256 logical, dimension(N**2), parameter :: A = .false. logical, dimension(N,N), parameter :: B = reshape ( (/ A /), (/ N, N /) ) end module Note: N=256 is the smallest number for which it fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-06 05:33 --- (In reply to comment #9) Even shorter: integer, parameter :: N = 256 Note: N=256 is the smallest number for which it fails. Workaround: Use a sufficiently large -fmax-array-constructor=n, e.g. -fmax-array-constructor=65536 (65536 = 256**2; default is 65535) Side remark: It is not particularly efficient to use a huge static variable. If you use PARAMETER (as in your example), that leads to huge .mod files and on assignment to large code. If you use a normal variable (with [implied] SAVE), a non-zero initializer will be written as is into the assembler file, which makes the binary unnecessarily large. For variables, using initialization at run time is the better choice for large arrays. The best solution for PARAMETER depends on the purpose. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-01 10:35 --- Please put it down for download somewhere (it's indeed too large to attach). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #2 from janus at gcc dot gnu dot org 2010-07-01 11:32 --- Also, please be more specific about which gfortran version you're using. Your error message seems to suggest something 4.5-ish. Is this the 4.5.0 release version? And is it possible for you to try 4.4.x or 4.6 trunk? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-01 11:45 --- Regarding the version: Try gfortran -v -- that does not only show the version but also the data and (possibly) the SVN reversion. Regarding the test case: I think it would be helpful, if you could reduce it a bit. Usually, it works best by removing all unneeded lines of the failing file - at the same time eliminating the number of required modules. That can also be automatized using Delta, cf. http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction But the suggestion to try GCC 4.6 (or 4.4) is also helpful. For GCC 4.6 binaries, see http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
[Bug fortran/44742] ICE in gfc_conv_array_initializer
--- Comment #4 from reuter at physik dot uni-freiburg dot de 2010-07-01 12:13 --- Ok, will do so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
