1

Running Intel Parallel Studio 2015 and Visual Studio 2012. Fortran 2003 compatibility turned on.

Is there an issue with the following code because it caused a very confusing (for me at least) heap corruption error on my machine and I'm trying to find out if it is something I'm not understanding correctly or a compiler bug.

character(len=200), dimension(:), allocatable :: inFNs
real*8, dimension(:), allocatable :: times

inFNs = (/ "file1.dat", "file2.dat", &
           "file3.dat", "file4.dat", &
           "file5.dat", "file6.dat" /)

allocate(times(SIZE(inFNs))
!more code below

The code would crash without a stack trace during the allocation of times, and it would tell me that a heap corruption occurred in a window dialog in debug mode.

The way I determined there was an issue with inFNs was because the issue would occur during a later allocate call if I moved the times allocation to be above inFNs.

The error has seemed to go away (knock on wood) by changing the declaration line to:

character(len=:), dimension(:), allocatable :: inFNs

I'm sorting through another issue in my code before I can know for sure.

In Response to Duplicate Question:

This is not a duplicate of the question suggested for so many reasons that I'm truly confused as to the marking. This question deals specifically with the syntax of an allocatable array of character arrays as opposed to alloctable arrays in general. This question deal with a potential compiler bug with Intel Visual Fortran while the other is a question on differences between Intel Fortran and gFortran. This question deals with a silent crash and heap corruption while attempting to use a separate array whereas the other deals with whether or not the array in question is considered allocated after an operation.

Even more to the point the answer in the second question is irrelevant to the issue present in this question as that option being turned on or off doesn't affect the issue presented.

To say these two questions are identical is like saying I was encountering crash with the following code

real :: number
number = 4.d0

and someone asking another question asking why there is an issue with the following

real :: number
number = 4
call add3ToDouble(number)

subroutine add3ToDouble(a)
    real*8 :: a
    a = a + 3.d0
end subroutine add3ToDouble

and saying the answer to both being "Because ifort defaults to real(kind=4)"

TrippLamb
  • 1,422
  • 13
  • 24
  • Sorry typo. I'll fix it. – TrippLamb Jan 10 '17 at 17:06
  • Typo in question* not code – TrippLamb Jan 10 '17 at 17:16
  • 2
    It may be just a compiler issue. What happens when you try with a current release? – IanH Jan 10 '17 at 19:43
  • No idea. As I don't have access to a more current release. – TrippLamb Jan 10 '17 at 20:00
  • 2
    In the code snippet above, you haven't allocated `inFNs` before specifying its values and so `size(inFNs)` is undefined... What happens if you add `allocate(inFNs(6))` before? – Ed Smith Jan 11 '17 at 10:20
  • 3
    As with the comment by Ed Smith, see [this](https://stackoverflow.com/q/22313883). – francescalus Jan 11 '17 at 10:22
  • In Fortran 2003 that is acceptable syntax. As I prove with the change that makes it go away. – TrippLamb Jan 12 '17 at 22:23
  • I'm sure if I did that suggestion it would be fine, but that is beside the point of the question. – TrippLamb Jan 12 '17 at 22:51
  • I reopened this question -- I agree with OP. But I suggest OP now tidies it up. I'd also like to see an [mcve] demonstrating the suspected bug. – High Performance Mark Jan 15 '17 at 10:46
  • If I get the time, I will attempt to create a full example. I don't have a compiler on my machine connected to the internet so it isn't as simple for me as it might otherwise be. I would like to note that the actual question asked (and I might could make that clearer) is really just trying to find out if "character(len=200), dimension(:), allocatable :: inFNs" is supposed to be allowable syntax or not. As the compiler does not throw an error even though it does not seem to work. – TrippLamb Jan 23 '17 at 17:40

0 Answers0