Internal compiler error with read statement

[Grady_Schofield]

The compiler is 10.1.3440.2008 . The following program produces an internal compiler error.

program disk_io_testimplicit noneinteger :: offset, size, filereal(8), pointer :: buffer( : )
size = 10allocate( buffer( size ) )offset = 2
file = 666open( unit=file, file='computational_temp', status='UNKNOWN', access='STREAM', form='BINARY' )read( unit=file, pos=offset ) buffer( 1 : size )end program disk_io_test
The problem is with the read line using "buffer( 1 : size )".
If I change "pointer" to "allocatable" in the declaration of buffer the problem goes away.
The error message is this
Error1 Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.S:srcdisk_io_testdisk_io_testdisk_io_test.f901

[Steven_L_Intel1]

I can reproduce this and will let the developers know - thanks. I'd recommend ALLOCATABLE anyway.

[Grady_Schofield]

The compiler version is as above is I go to Help -> About Microsoft Visual Studio -> Intel Fortran Compiler Integration, but the output window is saying:

1>Compiling with Intel Fortran Compiler 10.1.021 [Intel 64]...

I started this project with an evaluation copy. Maybe the compiler revved by the time I actually bought it, andthis project is stillusing the older compiler.

[Steven_L_Intel1]

With ACCESS='STREAM' you should not use FORM='BINARY' = 'UNFORMATTED' will do. The error seems to also require the use of POS=.

[Steven_L_Intel1]

10.1.024 is the compiler version and is the latest. The other version you noted is that of the Visual Studio integration. I understand this is confusing and a future release will include the compiler version there.

[Steven_L_Intel1]

Further investigation shows that this problem has already been fixed for a future major release.

[Grady_Schofield]

For some reason, when I posted this I thought it was only a problem for local variables. Now I find that pointers in structures have the same problem, and they have the problem whether the attribute is "pointer" or "allocatable". The only work around for this that I can think of is to allocate an array in the function that does the read, read into it, then do a copy from it to the locationwhere Ineed the data. This won't work however, because these reads are asynchronous and will persist past the end of the function call when the local array goes out of scope.

Is there any other way to set the file position so I don't have to use pos, or is there another syntax that Ican use in the read statement to denote a subsection of an array? Is there anything that I can do as a work around for this?

[Steven_L_Intel1]

I'm writing from home and can't test this, but some suggestions.

1. In your original test case, you did not need to say (1:size) - just naming the whole array should work.
2. An alternative is an implied DO loop, such as (buffer(i),i=1,size)

[Grady_Schofield]

The snippet was just cooked up from the actual code to demonstrate the error. In the real code it is imperative thatI be able to write contiguous pieces of the array. The implied do loop works! It seems that there is no performance penalty in using the implied do versus the ( 1 : size ) syntax ( in a case where that syntax works ). But let me get this straight - there are no compiler optimizations going on here, right? An implieddo does not technically mean"call read 'size' times". I don't want one of my users compiling the code with gfortran or something and that compiler generate a code thatissues 500 million calls to read. Is the implied doequivalent to the ( 1 : size ) syntax?

I think my problem is solved, but I've done some more testing and for people that might be looking at this thread for answers I'll say: Naming only the pointer without the ( 1:size ) syntax still causes the error as long as pos is present. It seems that using allocatable is not a viable fix either because for 2 dimensional arrays the problem reappears. For instance:

program read_bug2implicit nonereal(8), allocatable :: ptr( :, : )read(unit=1,pos=1) ptr(:, 1)end program read_bug2

[Steven_L_Intel1]

Semantically, the implied DO loop is the same as (1:SIZE), but I can't predict how other compilers might implement this. That said, the implied DO loop is a very common Fortran construct and compilers have been optimizing this for decades. I'd be very surprised if gfortran implemented this inefficiently.