[Bug fortran/44856] Usage of array PARAMETERs: Literal copy vs. global variable

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44856

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-09
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Concerning the test in comment 3, is "REAL_KINDS(i)" a constant if "i" is not?
IMO it is not and it is why I have used the convoluted code

do i=1,size(real_kinds)
  if (i == 1) then
write(s, '(2F4.1,2F4.0)') real(-9.4905,kind=j(1)), &
  real(9.4905,kind=j(1)),  &
  real(9.5,kind=j(1)), real(8.5,kind=j(1))
write(s1, '(3PE10.3,2PE10.3)') real(987350.,kind=j(1)), &
   real(98765.0,kind=j(1))
  else if (i == 2) then
...
  end if

in gfortran.dg/fmt_en.f90.

[Bug fortran/44856] Usage of array PARAMETERs: Literal copy vs. global variable

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-08 
16:28:07 UTC ---
Other example - from James,
cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1a695db0fcfaa3e9

program kindtest
   use ISO_FORTRAN_ENV
   implicit none
   integer i
   REAL_KINDS(1) = 42
   i = sum([(kind(real(0,REAL_KINDS(i))),i=1,size(REAL_KINDS))])
   write(*,*) i
end program kindtest

which is rejected with
  Error: 'kind' argument of 'real' intrinsic at (1) must be a constant

A quick test shows that for locally defined parameter arrays, only NAG f95 is
able to use it as KIND= argument to REAL. While g95, Intel, pathf95 and openf95
have the same problem as gfortran.

[Bug fortran/44856] Usage of array PARAMETERs: Literal copy vs. global variable

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-07-07 14:47 ---
My idea is:

a) For scalar expressions, generate simply always the scalar variable.

b) For array accesses, generate a const variable at the beginning of the
current block (subroutine, function, BLOCK) - if the variable is smaller than
-farray-parameter-inline-limit or if from an intrinsic module.

The trick for (b) is to collect this information in the symbol attribute (i.e.
not needed if never access or when only scalars are accessed). Additionally,
one needs to make sure that then in the current block the copied parameter is
accessed. I think a reasonable value for the limit could be something like 10,
20.

(I am actually not sure whether the FE does mark the module global parameters
variable as restricted or as constant. If one and if possible, one should do
so.)


An example. The trick is to make sure that  (ModulePara(1))  does not simply
generate, e.g., D.1558 = modulepara[0]; which is pointless.


module m
  integer, parameter :: ModulePara(2) = [ 1, 2 ]
end module m

program test
  use m
  implicit none

  integer :: (2),i
  i=1

   = ModulePara ! access modulepara (1)
  print *, ModulePara   ! access modulepara (2)
  print *, ModulePara(i)! access modulepara (3)
  print *, ModulePara(i)+i  ! access modulepara (4)
  print *, ModulePara(i)+1  ! access modulepara (5)

  (1) = (ModulePara(1)) ! use literal
  (1) = ModulePara(1)   ! use literal
  print *, ModulePara(1)! use literal
end program test

Dump contains the (correct!) six accesses to modulepara (5 + extern).


-- 


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

[Bug fortran/44856] Usage of array PARAMETERs: Literal copy vs. global variable

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-07-07 15:23 ---
Note: The tricky part for a simple fix is:
   moduleArray(i)

If one simply wraps in resolve_code the code-expr(1,2) with parentheses (e =
gfc_get_parentheses (e)) this leads to D.123 = modulearray[i], which does
not help for internal modules (cf. PR 40571) ...


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||rejects-valid


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