Crash with allocatable character variable that is declared with a fixed length

[johnyb_]

The following small program compiles without warnings or errors:

program test
    call s1('abc')
    
    contains
    subroutine s1(s)
        character(len=*), intent(in) :: s
        character(len=20), allocatable :: c
        c = s
        print *, c
    end subroutine
end program

But when executed it crashes, with more or less explicit messages depending on the compile options:

C:\TEMP>ifort test.f90 /debug:full /dbglibs
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.110 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 11.00.61030.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:test.exe
-debug
-pdb:test.pdb
-subsystem:console
test.obj

C:\TEMP>test
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
test.exe           00007FF66202806B  Unknown               Unknown  Unknown
test.exe           00007FF661FA1E62  Unknown               Unknown  Unknown
test.exe           00007FF661FA10C7  Unknown               Unknown  Unknown
test.exe           00007FF661FA103D  Unknown               Unknown  Unknown
test.exe           00007FF66208D02E  Unknown               Unknown  Unknown
test.exe           00007FF662026DEC  Unknown               Unknown  Unknown
test.exe           00007FF662026F2E  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFB64E016AD  Unknown               Unknown  Unknown
ntdll.dll          00007FFB668D34A5  Unknown               Unknown  Unknown

C:\TEMP>

adding /stand:f08 doesn't flag any warnings either.

I do think this is related to the fact that the character variable c is declared with a length and as allocatable, which must confuse the runtime.
I can not find something in the standard that would forbid this, but I can not see how it could be useful either. I stumbled across it when I changed some character variables from fixed size to allocatable and forgot to change the length to ":"

[mecej4]

Use the /standard-semantics or /assume:realloc_lhs options.

I think that as the years roll past us more users would expect /standard-semantics to be the default, and that compiler-vendor  extensions should be provided only if requested by the user.

[johnyb_]

In my second example of compile options I used /standard-semantics. I pasted a screenshot because the error message is in a dialog box. The only thing that changes from not using /standard-semantics is that I get an error from the windows runtime. Using /assume:realloc_lhs doesn't change anything.

I do not want to use this type of declaration, it happened by error. But as I wrote above,I don't know if the standard forbids this or if the compiler should diagnose it. In any case I think the compiler does not everything right here.

[mecej4]

I see; I did not attempt to read the text (dark-red, black background) in the screenshot closely. With the 16.0.1.139 build of the compiler (64-bit), I see a crash only with /stand:f08.

[Steven_L_Intel1]

I've now rewritten this response three times.

The program conforms to Fortran 2003. In our implementation, /assume:realloc_lhs (or /standard-semantics) is needed to get the automatic allocation on assignment. At first I thought assignment to a scalar didn't qualify for that, only arrays, but a careful reading of the standard tells me that it does qualify for allocation if not already allocated. 

However...  I can reproduce the error using the same options as in the screenshot. It seems to require that optimization be enabled. Very strange. I will escalate this to the developers.

[Steven_L_Intel1]

This was interesting.

The fundamental problem is that when the compiler does the automatic allocation, it incorrectly uses the length of the right-hand-side instead of the declared length. However, when it then does the copy, it uses the declared length, overwriting whatever comes after the allocated storage. With a declared length of 20 it's hit-or-miss as to whether the debug C library will pick up on the error, but if you increase the length to 2000, you'll get an error pretty much every time.

Escalated as issue DPD200379716.

[Steven_L_Intel1]

I expect the fix for this problem to be in the 16.0.2 compiler, scheduled for February.