Allocatable variable in namelist

[MR]

Hi,
consider the attached code. When compiling with -stand f03 I get
the following warning:

ifort -stand f03 abc.f90 -o abc
abc.f90(4): warning #8287: Fortran 2003 does not allow NAMELIST group object to be a function result.
namelist /input/ x
------------------^

ifort -V
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100414

The code, nevertheless, does "what is meant".

One question and one comment:

1) is there by now a consensus about the standard conformance of the
code? (Please, see also the related threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/76b23c9927b52161 )

2) in any case, ifort's warning seems misleading to me, since function
results have nothing to do with this problem.

Thank you, regards,
Marco



program abc

real, allocatable :: x(:)
namelist /input/ x

allocate(x(3))

open(15,file='infile.in')
read(15,input)
close(15)

write(*,*) x

deallocate(x)

end program abc

[MR]

By the way: with -stand f95 I get

ifort -stand f95 abc.f90 -o abc
abc.f90(4): warning #8287: Fortran 95 does not allow NAMELIST group object to be a function result.
namelist /input/ x
------------------^

In fact, this is illegal in f95, so the warning is correct, but again
function results are not involved.

Marco

[mecej4]

ALLOCATE is a "function", albeit an intrinsic procedure.

ALLOCATE is called with x as the argument. Thus, the address of x may change after the ALLOCATE procedure is called. It would be a problem for the compiler to issue code to keep track of a NAMELIST whose list elements are not at fixed locations.

With your code, another compiler says:

Error: marco.f90, line 16: Namelist-group-object X is ALLOCATABLE

[MR]

mecej4,
thank you for your explanation, however I still think that the
warning message is not pointing to the right thing.

Specifically, notice that - to my understanding -

1) ALLOCATE is a statement, it's not an intrinsic function nor
procedure

2) I don't see any prohibition about namelist group objects appearing
as procedure actual arguments, nor to the lhs of an assignment
involving a function: the following code is fine

program test
implicit none
real :: x(3)
namelist /input/ x

interface
function fun(n)
integer, intent(in) :: n
real :: fun
end function fun
end interface

call sub(x)

x = fun(5)

end program test

3) the warning message of the other compiler you mention seems
perfectly clear to me: it points to the fact that x is allocatable
while also being a namelist group object (prohibited in f95, not so
clear for f2003).

Regards,
Marco

[mecej4]

In support of your position, the Fortran 2003 standard says in Section 9.5.3.6: Every allocatable namelist-group-object in the namelist group shall be allocated and every namelist-group-object that is a pointer shall be associated with a target.

I could not locate any statement that amouts to prohibition of allocatable arrays from being "namelist-group-objects". That a section (see above) specifies rules for such objects implies that they are allowed in F2003.

I hope that an Intel representative will respond on this question.

-------------------------------------
I was interpreting the word 'function' in the IFort error message not in the narrow Fortran sense, but in the sense that ALLOCATE(X(3)) corresponds to double *X = (double *)calloc(3,sizeof(double)) in C.

I personally think that the syntax of the ALLOCATE statement will be confusing to newcomers to Fortran. X is a variable that often has neither address nor value before the statement, and the 3 within parentheses is neither a subscript nor a function argument in the Fortran sense. If fact, X is an address that is returned, and 3 is a value argument to the allocation function/procedure.

I would have found ALLOCATE(X,3) or ALLOCATE(X,1,3) to be better. However, the syntax is entrenched, so complaining about it will accomplish nothing.

[Kevin_D_Intel]

The warning is confusing. I'll check w/Development and update again with their comments.

[MR]

Quoting mecej4

I was interpreting the word 'function' in the IFort error message not in the narrow Fortran sense, but in the sense that ALLOCATE(X(3)) corresponds to double *X = (double *)calloc(3,sizeof(double)) in C.

I personally think that the syntax of the ALLOCATE statement will be confusing to newcomers to Fortran. X is a variable that often has neither address nor value before the statement, and the 3 within parentheses is neither a subscript nor a function argument in the Fortran sense. If fact, X is an address that is returned, and 3 is a value argument to the allocation function/procedure.

I would have found ALLOCATE(X,3) or ALLOCATE(X,1,3) to be better. However, the syntax is entrenched, so complaining about it will accomplish nothing.

Yes, I agree about the C code. There are various things in the
language that "look like functions", at least in the way they
"function", but have a dedicated syntax: mostly I/O comes to my mind
(WRITE, PRINT, OPEN, CLOSE) but also NULLIFY. In fortran terms, they
look very much like PROCEDURES, but they don't use the CALL statement.
And to add another twist (!), one can define

SUBROUTINE ALLOCATE(X,N)
REAL, ALLOCATABLE, INTENT(OUT) :: X(:)
INTEGER, INTENT(IN) :: N
ALLOCATE(X(N))
END SUBROUTINE ALLOCATE

and then

CALL ALLOCATE(X,3)

Maybe there are reasons to avoid intrinsic procedeures, maybe the new
f2003 concepts benefit from this choice, no idea. Anyway...

Regards,
Marco

[Kevin_D_Intel]

After some additional testing I found the warning has been improved in the upcoming major release due later this year. It now reads:

sample.f90(4): warning #8285: Fortran 95 does not allow a NAMELIST group object to be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array.

namelist /input/ x

------------------^

The warning is appropriately issued when compiling with -stand f90 or -stand f95. It is no longer issued when compiling with -stand f03 (or without since that is new default in the upcoming 12.0 compiler).

It unfortunately is incorrectly issued when compiling with -stand f08. I notified Development about this and it will be corrected in an update next year.

(Internal tracking id: DPD200160735)

(Resolution Update on 02/21/2011): This defect is fixed in the Intel Fortran Composer XE 2011 Update 2 (2011.2.137 - Linux)

[Kevin_D_Intel]

This defect is fixed in the Intel Fortran Composer XE 2011 Update 2 (2011.2.137 - Linux)