realloc_lhs, allocatable characters, and debugger

[abhimodak]

Hi

I am seeing the following with 11.1.054. I know that similar discussions have been on this forum, my apologies, but I want to report the status as it is now.

(1) Using /assume:realloc_lhs

(a) Is this option available through IDE(other than command-line--Additional Options)? I tried to see it through help page using /assume but could not see it in the IDE equivalent. May be I am not looking at the right place.

(b) If it's not used, there is no compile time error message and I don't think there will be a run-time message either (as mentioned by Steve http://software.intel.com/en-us/forums/showthread.php?t=66647). However, I think since using the compiler switch is required to conform to the standard, there should be at least be a run-time exception when running in debug mode. Is that a fair request for enhancement?

I believe that the switch is required is a good thing but without an exception it still leaves something to chance. (Of course, I am not advocating lazy programming.)

(2) It seems this switch is not needed for allocatable character variables. For example, the following does assign String == Fortran even when I don't add /assume:realloc_lhs at the command line additional option in the IDE.

Program Test_AllocatableChar
Implicit None
Character(:), Allocatable :: String
String = 'Fortran'
Print *, String
End Program Test_AllocatableChar

The following also works without using the switch:
Program Test_AllocatableChar
Implicit None
String = "Intel"
Print *, String, Len(String)
String = "Fortran"
Print *, String, Len(String)
End Program Test_AllocatableChar
The second assignment does print "Fortran" and "7".

(3) However, reading from console or input file does not work irrespective of whether I use the switch or not. Thus,

Program Test_AllocatableChar
Implicit None
Character(:), Allocatable :: String
Print *, "give a string"
Read *, String
Print *, String, LEN(String)
End Program Test_AllocatableChar

Running the above program will print nothing (empty) for String and the length of the string is 0.

I believe that I am violating the standard here...am I?

(4) I wonder if IVF is strictly conforming to the standard in the following snippet.

Program Test_AllocatableChar
Implicit None
Character(:), Allocatable :: String(:)
String = ["Intel", "Fortran"]
Print *, String
Print *, Size(String)
Print *, LEN(String(1)), LEN(String(2)), LEN_Trim(String(1))
End Program Test_AllocatableChar

While this is nice i.e. the length type parameter 'automatically' adjusts to the largest value == 7 in this case; does it violate: "All elements in an array constructor must have same type and type parameters"? Of course the end result from IVF conforms to the standard by automatically interpreting the array constructor statement as String[Character(7) :: "Intel" "Fortran"]. Is it allowed by some special rule on the "LEN" type parameter?

(5) In all these cases, the debugger does not show the allocatable character variable correctly. The debugger watch window says: "Substring arguments out of bounds". Also even if the variable is in the watch window, when the program is re-run it remains greyed-out when debugging again.

Sincerely
Abhi

[Steven_L_Intel1 · Accepted solution]

1a: No, /assume:realloc_lhs is not available as a property in the IDE

1b: I don't understand the request. Without the switch, you get Fortran 90/95 semantics that require the allocatable array on the left side to already be allocated to the same shape as the right. We don't currently offer shape checking, which is perhaps what you are asking for. Depending on what the left side is, you may get an access violation, you may get a bounds error, or you may get data corrupted.

2: No, the switch is not needed for allocatable deferred-length character variables. It was in some earlier updates to 11.1, but we fixed that.

3: You don't get the automatic allocation semantics except in an assignment. On a READ, you must allocate it appropriately first.

4: That's an extension we have. You are correct that, to conform to the standard, your code must specify the length (a new F2003 feature). Since your source is not standard-conforming, the compiler can do whatever it pleases, which is to give you the length of the longest value.

5: We know about that and are working on it.

[abhimodak]

Many thanks, Steve. It was really a long post with probably not much value in it.

1b: My mistake! No enhancement needed.

4. I confirmed that using /stand:f03 correctly traps the error if I don't give the LEN and the array elements are of different length. If the array elements are of the same length, the LEN specification can be omitted, which I think is allowed by the standard, and thus 11.1.054 rules! :)

Sincerely
Abhi

[Steven_L_Intel1]

Yes - if the lengths are all the same that's fine.

Incidentally, you're not the first to think that READ should also do the automatic allocation. Nice idea, but it doesn't work that way.