Expected Behavior for random_number() with Improper SEED array

[Watson__Timothy]

What would be the expected behavior of random_seed and/or random_number if one were to pass as an array argument to random_seed a variable initialized as an array of size < N, where N is the value of the integer returned from executing random_seed with SIZE?  Specifically, for v16.0.1 of IFC if the behavior has changed over time.  Below is a snippet of code to illustrate the point, pardon any syntax errors:

program main

implicit none

integer :: i

integer, allocatable, dimension(:) :: x

real :: y

call random_seed(SIZE=i)

write(*,*) 'Seed array size = ', i

***Assume the above writes 'Seed array size = 2' to STDOUT.***

allocate(x(1))

x = 38433

call random_seed(PUT=x)

call random_number(y)

end program main

[Steve_Lionel]

As was discussed in comp.lang.fortran, the program is not standard-conforming and thus anything can happen. What Intel Fortran does is interesting (I modified your program to explore behavior). If you do a PUT with a one-element array, it uses that one element and then does.. something else with the second part of the seed. It isn't fetching the next location, but I'm not entirely sure what it does.

I would agree with those in c.l.f. that this is a "quality of implementation" issue. My preference would be for this to cause a run-time error. Feel free to submit a request to Intel for this.

[Watson__Timothy]

For a toy program given above, two executions will generate the same pseudo-random number sequence.  For a larger (subjective interpretation) program that has a larger and more dynamic memory footprint that calls shared objects at run time, the pseudo-random sequence changes.  This suggests (but doesn't prove) that it's possible the second expected array element value is getting pulled from a location in memory.  In the toy program, its possible this location is held static and the second array element value never changes, while in the larger program, it does.   Does this sound reasonable?  I intend to submit a support request ticket to sharpen the pencil on this one.  Thank you.

[Watson__Timothy]

After going through a prolonged process for submitting a support ticket, the individual who was tasked with trouble shooting this issue indicated that the next integer-size chunk of memory is accessed to set the second required seed value.  They then went on to say that the -check shape option does not catch this error and that a feature request would be put in to do so.  I'm now curious if 1) there is any way random_seed() could be modifying the data in that next chunk of memory, thus introducing an error in the remainder of the program in question or in some other process, and 2) how does random_seed() handle non-conforming seed value input to the requirements of the algorithm? Is it possible it performs some intermediate operation on it like a modulo?