------- 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
