This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Infamous PR fortran/19925
On Sun, Sep 14, 2008 at 11:38:29AM +0200, Richard Guenther wrote:
> On Sun, Sep 14, 2008 at 11:20 AM, Paul Richard Thomas
> <paul.richard.thomas@gmail.com> wrote:
> > Steve,
> >
> > On Sun, Sep 14, 2008 at 7:17 AM, Steve Kargl
> > <sgk@troutmask.apl.washington.edu> wrote:
> >> Well, I spent some time last week thinking about PR
> >> fortran/19925 and have decided that the best option
> >> may be to punt. Consider the somewhat far fetched
> >> but legal Fortran,
> >
> > I concur with you completely on this. I have visited this PR on one
> > or two occasions and have failed to come up with any better
> > alternative. Maybe a warning like that at the head of module files
> > should be emitted? :-)
>
> Are you really required to expand these declarations at compile-time
> (Yes, I see these are PARAMETERS, but ...)? Otherwise I would suggest
> to promote them (and dependent parameters) to static storage that is
> runtime-initialized.
>
AFAIK, the Fortran standard does not require compile-time
expansion. At least 5 gfortran developers have at some
point looked at this PR (paul, jerry, erik, thomas, and me),
and no one has been able to come up with an alternate solution.
I've thought about runtime-initialization although admittedly
I don't know how to implement it. Consider, the following
program test
implicit none
integer j
integer, parameter :: n = 10, m = n / 2 + 2
integer, parameter :: i(n) = (/ (2*j, j = 1, n) /)
real, parameter :: dpi = 6.283185 / (i(m) - 1)
real :: x(i(m)) = (/ ((j-1) * dpi, j = 1, i(m)) /)
do j = 1, i(m)
x(j) = sin(x(j))
end do
print *, x
end program test
gfortran would need to implement run-time initialization of
i and dpi as well as run-time memory allocation of x and
its initialization. I haven't given much thought about the
possible complications with regards to passing x to routines
that have assumed-sized and assumed-shape dummy arrays.
Then, there is the fun complication of derived types. This
is legal.
program test
implicit none
type point
real :: x = 0, y = 0, z = 0 ! default-initialization at origin
end type point
integer j
integer, parameter :: n = 1000000
type(point) :: p(n) = (/ (point(j,j,0), j = 1, n) /) ! straight line y = x
print *, p(2)
end program test
While run-time initializatio of the above may be possible, derived
types can get complicated quickly.
--
Steve