Error or compiler bug?
mecej4
$ pgf95 -Mallocatable=03 -c tst.f90
"PGF90-S-0134-Illegal attribute - conflict with allocatable (tst.f90:
4)"
when given the test code
subroutine sub(m,val,stat)
implicit none
integer, intent(in) :: m
real, optional, allocatable :: val(:)
integer, optional, intent(out) :: stat
if(present(val))then
allocate(val(2))
stat=1
else
stat=0
endif
return
end subroutine sub
Is there an error in this subroutine? Thanks.
Les Neilson
"mecej4" <mec...@gmail.com> wrote in message
news:07ed71ea-1c23-4266...@r15g2000prh.googlegroups.com...
Yes. You haven't tested if "stat" is present before assigning to it.
Les
glen herrmannsfeldt
What does -Mallocatable=03 do?
> "PGF90-S-0134-Illegal attribute - conflict with
> allocatable (tst.f90: 4)"
(snip)
> real, optional, allocatable :: val(:)
> integer, optional, intent(out) :: stat
> if(present(val))then
> allocate(val(2))
> stat=1
> else
It looks legal to me: From F2003 12.4.1.6, regarding
optional arguments that are not present:
"If it is allocatable, it shall not be allocated, deallocated,
or supplied as an actual argument corresponding to an optional
nonallocatable dummy argument."
It might be that this is new in Fortran 2003, though.
-- glen
fj
Your compiler needs to implement FORTRAN-95 + TR15xx (extension
concerning ALLOCATABLE arrays and included in F2003). If the compiler
just implements F95, then the error message is normal (an allocatable
array cannot be an actual argument).
The fact that you do not test the presence of the variable "stat" is
not an error. But It will become a true error if the caller does not
provide the "stat" argument.
glen herrmannsfeldt
(someone wrote)
>> when given the test code
>> subroutine sub(m,val,stat)
>> implicit none
>> integer, intent(in) :: m
>> real, optional, allocatable :: val(:)
>> integer, optional, intent(out) :: stat
>> if(present(val))then
>> allocate(val(2))
>> stat=1
>> else
>> stat=0
>> endif
>> return
>> end subroutine sub
>> Is there an error in this subroutine? Thanks.
> Yes. You haven't tested if "stat" is present before
> assigning to it.
I disagree. That is an error if, in fact, it is called
with val present and stat absent. If it is never called
that way then it should be legal, and the compiler
shouldn't enforce that restriction.
It seems, though, that the compiler is restricting optional
allocatable arguments.
-- glen
mecej4
Thanks. However, it was an oversight on my part to make 'stat'
'optional' while making up a short example. Removal of 'optional' as
an attribute of 'stat' does not make the compiler error message go
away.
-- mecej4
Richard Maine
> Les Neilson <l.ne...@nospam.co.uk> wrote:
> (someone wrote)
> >> Is there an error in this subroutine? Thanks.
>
> > Yes. You haven't tested if "stat" is present before
> > assigning to it.
>
> I disagree. That is an error if, in fact, it is called
> with val present and stat absent. If it is never called
> that way then it should be legal, and the compiler
> shouldn't enforce that restriction.
I agree with glen here. Nothing at all illegal about that. Perhaps an
error-prone style, which I wouldn't use, but not illegal.
> It seems, though, that the compiler is restricting optional
> allocatable arguments.
Perhaps, but I see no evidence of this. Unless I missed it, nothing
posted specifically points to the optionality as being related. The
argument does happen to be optional, but it has plenty of other
properties as well. While it is possible that the optional attribute
might be related, this appears to me to be a guess based on insufficient
data.
I would consider it a more straightforward guess that what conflicts
with allocatable is the property of being a dummy argument. This seems
particularly likely because that combination is, in fact, illegal in f95
unless the compiler also supports the allocatable TR.
Admitedly, my guess is also just a guess, but it is sure one I'd want to
eliminate before going on to more essoteric ones.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
mecej4
> mecej4 <mec...@gmail.com> wrote:
> > PGI 7.1x says
> > $ pgf95 -Mallocatable=03 -c tst.f90
>
> What does -Mallocatable=03 do?
>
From the manual:
".. controls whether Fortran 95 or Fortran 2003 semantics are used in
allocatable array assignments. The default behavior is to use Fortran
95 semantics; the 03 option instructs the compiler to use Fortran 2003
semantics .."
<<---CUT--->>
> It might be that this is new in Fortran 2003, though.
>
Although I could not find mention of TR-15581 in the compiler RM,
http://www.polyhedron.com/pb05-linux-language0html lists the 7.1.6
version of the PGI compiler as one that implements the extensions.
Thanks for your comments.
-- mecej4
mecej4
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > (someone wrote)
>> <---CUT --->>>
>
> I agree with glen here. Nothing at all illegal about that. Perhaps an
> error-prone style, which I wouldn't use, but not illegal.
>
> > It seems, though, that the compiler is restricting optional
> > allocatable arguments.
>
> Perhaps, but I see no evidence of this. Unless I missed it, nothing
> posted specifically points to the optionality as being related.
Thanks. What you wrote strikes me as quite reasonable and logical.
However, further testing shows that, as seen by this compiler,
it is, indeed, the 'optional' attribute that triggers the spurious
bug.
The shorter example
subroutine sub(m,val)
implicit none
integer, intent(in) :: m
real, allocatable,optional,dimension(:) :: val
if(present(val).and.not.allocated(val))allocate(val(2))
return
end subroutine sub
causes a compiler syntax error message, but leaving out the "optional"
and checking for present(val) makes the message go away.
I have not seen the TR 15581, so I do not know whether a vendor my
implement part of the TR extensions (allocatable array arguments) and
leave out others (optional allocatable array arguments).
-- mecej4
glen herrmannsfeldt
(snip, I wrote)
>> It seems, though, that the compiler is restricting optional
>> allocatable arguments.
> I would consider it a more straightforward guess that what conflicts
> with allocatable is the property of being a dummy argument. This seems
> particularly likely because that combination is, in fact, illegal in f95
> unless the compiler also supports the allocatable TR.
The message could be more clear. Since I don't usually think
of 'dummy' as an attribute, but allocatable and optional are
usually attributes, that might be why I thought about it that way.
> Admitedly, my guess is also just a guess, but it is sure one I'd want to
> eliminate before going on to more essoteric ones.
-- glen
glen herrmannsfeldt
(snip, I wrote)
>> What does -Mallocatable=03 do?
> From the manual:
> ".. controls whether Fortran 95 or Fortran 2003 semantics are used in
> allocatable array assignments. The default behavior is to use Fortran
> 95 semantics; the 03 option instructs the compiler to use Fortran 2003
> semantics .."
I presume that means Fortran 2003 allocate on assignment.
It would seem strange to include that, along with such an
option, but not the other features of Fortran 2003 allocatables.
-- glen
Les Neilson
In my defense it was past going home time, and I read and replied rather
hurredly.
Les
mecej4
To add to your defense: your reasoning may have been flawed but your
conclusion was on the dot. I am beginning to conclude that, when
trying to concoct a simple example to pin down and demonstrate a
compiler bug, shooting in the dark may succeed whereas perfect logic
would fail!
Thanks
-- mecej4 (mecej4_at_operamail.com)