https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79402
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-02-07
CC| |pault at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Paul Thomas <pault at gcc dot gnu.org> ---
Dear Stefano (and Chris),
I can confirm that the bug is there on the latest 7.0.1. This is the
minimum testcase that exhibits the problem.
module mod
interface myfun
module function fun1(n) result(y)
integer, intent(in) :: n
real, dimension(n) :: y
end function fun1
end interface myfun
end module mod
submodule (mod) submod
contains
module procedure fun1
end procedure fun1
end submodule
It appears that 'n' doesn't get treated as a dummy for reasons that I
do not see right now.
Bizarrely, this works perfectly and might be a good workaround for
you, omitting the 'source' part of the allocate, if you are assigning
to y somewhere else:
module mod
interface myfun
module function fun1(n) result(y)
integer, intent(in) :: n
real, allocatable, dimension(:) :: y
end function fun1
end interface myfun
end module mod
submodule (mod) submod
contains
module procedure fun1
allocate (y(n), source = [(float(i), i = 1,n)])
end procedure fun1
end submodule
use mod
print *, fun1(5)
end
I don't feel much like a 'superhero' right now:-( I have spent the last month
moving between countries and have only just got set up to do anything
gfortran-ish in the last 24 hours.
Thanks
Paul
