Optional assumed length allocatable character array

[Jacob_Williams]

I have some code that worked fine on release 10.1, but is crashing with an access violation on 11.1.065. It is a routine that has an assumed length allocatable, optional character array. An simplified example is:

[fortran]module routines
implicit none
contains
subroutine routine (b)
implicit none
character(len=*),allocatable,dimension(:),intent(out),optional :: b
end subroutine routine
end module routines

program test
use routines
implicit none
character(len=10),allocatable,dimension(:) :: b
call routine(b)		!doesn't crash
call routine()		!crashes
end program test[/fortran]

When I don't use the optional argument b, it crashes with an access violation. Is this a compiler bug? Or is the code not valid fortran syntax?

[Steven_L_Intel1]

It's a compiler bug. The compiled code should be checking to see if the argument is omitted before doing the INTENT(OUT) deallocation. I'll let the developers know. Thanks. Issue ID is DPD200155112.

Curiously, I find that the error goes away if you compile with normal optimization (O2) - it fails only with O1 or Od (disabled) optimization.

[Steven_L_Intel1]

This will be fixed in a future release.

[mecej4]

The same bug is also seen in the current Linux x64 version of the Intel compiler (SIGSEGV with -O0, not with -O2).

In the course of simplifying the code for posting here, lines have been removed from which the intent/usage of the assumed size character array could have been inferred -- for example, the lines in which b is allocated.

It may be that rather than making b an assumed length character variable, making it a deferred length character variable would be a better fit to the intended usage in the program. If so, the length declarations on lines 6 and 13 can be changed to len=: . If these changes are made, the program may be compiled and run with no errors with either -O0 or -O2.

[Steven_L_Intel1]

Strictly speaking, b is a "passed-length" character variable.

[Jacob_Williams]

Just to follow up on the original post: this issue is indeed fixed in version 12.0.3.175 of the compiler.