topic Yes, it's a compiler bug. You in Intel® Fortran Compiler

Runtime Error

Michael8 — Tue, 25 Apr 2017 20:47:29 GMT

Hello:

I am getting a runtime error, and I was hoping that somebody could help explain to me exactly what is going on. I am running windows 10, Visual Studio 2015, and compiler version 17.0.2.187, in Debug Mode. When I run in Release Mode there is no runtime error (which doesn't surprise me). And if rollback to use the XE 15.0.4.221 compiler, I also don't get an error (even in Debug Mode).

I have stripped down the program to create a simple example that still gives me the runtime error. I have attached the solution file, project file, source code file, and the input file. Since it's a pretty short sample program, I'll paste it here for convenience:

program Test

call TempSub(1)

contains

subroutine TempSub(low)

integer :: low

integer :: intVar
double precision, dimension(low:2) :: arr

open(unit=13,file="test.txt")
read(13,*) intVar,arr(:)
close(13)

end subroutine TempSub

end program Test

The error I get is:

forrtl: severe (157): Program Exception - access violation

And it tells me that it happens on line 15 (the "read") line. If I change line 15 from:

read(13,*) intVar,arr(:)

to:

read(13,*) intVar,arr

then it also runs fine (no runtime error).

Can someone please explain to me what's going on with this short piece of code? I'm not sure if what I'm trying to do is illegal, or if perhaps this is a compiler bug.

Thanks for your help.
Michael

What you are doing is

Steve_Lionel — Tue, 25 Apr 2017 21:00:16 GMT

What you are doing is perfectly valid - a runtime error would be inappropriate. But I do generally recommend against using (:) to say "hey, this is an array!", as in some cases it can bite you. One of the Intel folk will take a look.

Thanks. So basically you're

Michael8 — Wed, 26 Apr 2017 13:02:58 GMT

Thanks. So basically you're saying that there is not a coding error, but maybe this is a bug in the compiler. Is that right?

But you're also saying that even though there's technically no coding error, the coding style should be avoided. Can you elaborate a little bit (or perhaps provide a link to a useful article) on why/how this coding style would not be best practice?

Thanks.
Michael

Yes, it's a compiler bug. You

Steve_Lionel — Wed, 26 Apr 2017 15:25:00 GMT

Yes, it's a compiler bug. You want an article? Ok! https://software.intel.com/en-us/blogs/2008/03/31/doctor-it-hurts-when-i-do-this

Thanks for clarifying, and

Michael8 — Wed, 26 Apr 2017 17:40:56 GMT

Thanks for clarifying, and thanks for the link to that article. Very helpful!

Michael

The error occurs in relation

Kevin_D_Intel — Wed, 26 Apr 2017 17:59:10 GMT

The error occurs in relation to the Debug build having /check:bounds enabled. You can avoid it by making the suggested source modification or for the Debug build disabling (setting to No) bounds checking under the IDE via Properties > Fortran > Run-time > Check Array and String Bounds.

As Steve indicated, this should not result in a run-time failure with bounds checking enabled. I reported that to Development. This appears to be a regression with our 17.0 release. The test case compiles/runs successfully with pre-17.0 releases. Thank you also for the convenient test case.

(Internal tracking id: CMPLRS-42642)

Thanks for reporting it to

Michael8 — Wed, 26 Apr 2017 19:08:12 GMT

Thanks for reporting it to Development, and for that alternate workaround. That may be a helpful alternative for some of our programs that were running into this issue.

Michael

One point of the article

Steve_Lionel — Thu, 27 Apr 2017 14:47:45 GMT

One point of the article needs updating, but I can't do that anymore (maybe I can convince Kevin to do it for me?)

It's where I write:

This is why Intel Fortran does not support this F2003 feature by default - you have to ask for it with the option /assume:realloc_lhs, or for Linux and Mac users, -assume realloc_lhs. ("lhs" here means "left hand side".)

This was true when I wrote it in 2008, but as of compiler version 17 the F2003 behavior is the default.

However, on revisiting this article I see I made a horrible error that nobody has called me on in seven years! It's this paragraph:

But there's another case where the (:) can bite you. If you are calling a procedure where the corresponding dummy argument is a deferred-shape array, then there is a difference in meaning to passing the array name A and passing A(:). If you just pass A, then the lower bound(s) are passed along and are reflected in the dummy argument inside the called routine. However, if you pass A(:), that's an array section and the lower bound is 1, no matter what you declared it as originally. This will change how the array is indexed in the called procedure and can cause array bounds violation errors.

This entire paragraph is simply wrong - the only time the array bounds are passed is when the dummy argument is a POINTER - in all other cases the lower bound is 1 and the upper bound is the extent of the dimension. This paragraph should be deleted. Kevin, would you please do the honors?

Happy to do that Steve and

Kevin_D_Intel — Thu, 27 Apr 2017 18:34:43 GMT

Happy to do that Steve and have done so.

Perfect - thanks! (Me so

Steve_Lionel — Thu, 27 Apr 2017 19:22:32 GMT

Perfect - thanks! (Me so embarassed!)