- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for clarifying, and thanks for the link to that article. Very helpful!
Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Happy to do that Steve and have done so.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Perfect - thanks! (Me so embarassed!)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page