This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]