Debug breakpoints are hit on entry to subroutine although code is never executed.

[thomas_boehme]

There seems to be a debugger problem related to allocatable objects, in particular with allocatable, deferred length strings.

Upon entering a subroutine, debug breakpoints are hit, although the code in that line is never executed at all. This seems to be always related to some allocatable variables.

E.g. in the attached code, set a breakpoint within both CASE statements on the String = ... lines. These breakpoints should never be triggered, as the argument I pass to the routine is neither ABC nor DEF.

However, when running in debug mode, the breakpoint in the second case does get triggered, although the line of code is indeed not executed, which can be verified by the correct on screen output.

I know that for the example, the TRIM in the select case would not be necessary, but the problem only occurs with the TRIM. It does occur in multiple other scenarios, however, the example was the easiest I could come up with as a demonstrator.

The behavior is really annoying as we have already spent significant time wondering about why some IF's blocks are executed, etc. when the shouldn't, only to later find out that they are NOT executed, an it's just a debugger problem...

Best regards,
Thomas

[fortran]    SUBROUTINE WrongBreaks(In)
    CHARACTER(*) :: In
    CHARACTER(:), ALLOCATABLE :: String
    String = In    
    SELECT CASE (TRIM(String))
        CASE ('ABC')
            String = 'abc' 
        CASE ('DEF')
            String = 'def'
    END SELECT
    WRITE (*,*) String
    END SUBROUTINE
    
    program BreakAtWrongLocation
    implicit none
    CALL WrongBreaks('Test')
    end program BreakAtWrongLocation

[/fortran]

[Steven_L_Intel1]

It's not a debugger problem, per se. If you look at the assembly code, you'll see two instructions just before the SELECT CASE that are assigned to the line "string = 'def'". It is not immediately clear to me why the compiler chose to assign this line here. I'll ask our compiler debug info experts about it.

I have seen this general issue in other programs, where a breakpoint is hit long before the actual code for that line is executed. I agree that it can be annoying.