Scope of global variables

Dear all,

Consider the following program:

--CUT HERE--
program type_alloc_bug

type my_type
integer, dimension(:), allocatable :: data
end type my_type

type(my_type), dimension(:), allocatable :: my_type_array

call alloc()

print *, SIZE(my_type_array), ALLOCATED(my_type_array)
print *, my_type_array(1)%data

contains

subroutine alloc ()

integer :: i

allocate(my_type_array(10))

do i = 1,10
allocate(my_type_array(i)%data(2))
my_type_array(i)%data = (/i,i/)
end do

end subroutine alloc

end program type_alloc_bug
--CUT HERE--

I expect this program to give the following output:

10 T
1 1

However, when compiling using the Intel Fortran Compiler for Linux
(8.1.023), I get the following output:

10 F
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC        Routine            Line        Source

type_alloc_bug     0804A215  Unknown               Unknown  Unknown
type_alloc_bug     0804A188  Unknown               Unknown  Unknown
Unknown            40087410  Unknown               Unknown  Unknown
type_alloc_bug     0804A041  Unknown               Unknown  Unknown

It appears that my_type_array is losing its allocation status upon
return to the main program.

I've submitted this to Intel as a bug, but they have suggested I simply
add the SAVE attribute to my_type_array. This certainly fixes the
problem; but surely this is a workaround rather than a fix? Since
my_type_array is declared in the main program, its scope is global, and
it should *never* lose its allocation status. Therefore, the addition of
the SAVE attribute is just masking a problem with global scope. Is my
thinking correct?

cheers,

Rich

--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]

Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:

[code elided]

> I've submitted this to Intel as a bug, but they have suggested I
> simply add the SAVE attribute to my_type_array. This certainly fixes
> the problem; but surely this is a workaround rather than a fix? Since
> my_type_array is declared in the main program, its scope is global,
> and it should *never* lose its allocation status. Therefore, the
> addition of the SAVE attribute is just masking a problem with global
> scope. Is my thinking correct?

Yes, your thinking is correct (or at least in agreement with mine :-)).
For additional "ammunition" (though I think your argument alone is
quite sufficient), you can quote the para before Note 5.17 in the f95
standard.

"A SAVE statement may appear in the specification part of a
main program and has no effect."

I happen to think that particular statement in the standard is
redundant, and thus better belongs in a note explaining it as
a consequence of the other rules.

Anyway, the "has no effect" part seems about as explicit as one
could ask for.  I think that an implementation in which it has
an effect is buggy.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Richard E Maine wrote:
> Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
>
> [code elided]
>
> 
>
>
> Yes, your thinking is correct (or at least in agreement with mine :-)).
> For additional "ammunition" (though I think your argument alone is
> quite sufficient), you can quote the para before Note 5.17 in the f95
> standard.
>
>   "A SAVE statement may appear in the specification part of a
>    main program and has no effect."
>
> I happen to think that particular statement in the standard is
> redundant, and thus better belongs in a note explaining it as
> a consequence of the other rules.
>
> Anyway, the "has no effect" part seems about as explicit as one
> could ask for.  I think that an implementation in which it has
> an effect is buggy.
>

Thanks for the quote; I've included it in my response to Intel. FWIW,
although the SAVE attribute 'fixes' the problem in the test code I
posted, it didn't make any difference to my production code.

cheers,

Rich

--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]