------- Comment #4 from paul dot richard dot thomas at cea dot fr  2006-09-01 
13:45 -------
(In reply to comment #3)
> Setting the parameter n=65535, the program appears to execute correctly. 
> However, the pr28914.f90.003t.original file is 706800 bytes long and embedded
> with a very large static declaration of the array.  As if it has been inlined.
> With n=66536, the dump file is 4436 bytes long and has code to initialize the
> array with a loop.  That looping code appears broken.

The looping code, of itself, is not broken.  If one of the 'i's, say in the
implied do-loop, is changed to 'j', the code runs to completion.  The problem
is that the implied do-loop counter uses a variable declaration and so a
symbol.  This clashes with the variable i.

Since do-loops can run with +ve or -ve steps, the end condition is enforced
through:

            L.1:;
            D.931 = i == 1;
            i = i + 1;
            if (D.931) goto L.2; else (void) 0;

ie. with an equality.  The implied do-loop sets this larger than 1 so the loop
never stops.

For n < 65536, the loop is simplified out of existence and the large static
array makes its appearance.  This seems to be an undesirable consequence of
treating array initializers and array constructors with the same limit.

I would:

(i) Change the size limit for simplification of array constructors; and
(ii) Store the current value of the loop counter in a temporary and restore it
after the array constructor has done its thing (patch follows).

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914

Reply via email to