ICE + ELEMENTAL + allocatable-length character

[John4]

In the code below, I get an ICE. that seems to be caused by the combination of ELEMENTAL keyword (in the function some_verification) and allocatable-length character variable string. By removing the ELEMENTAL keyword or changing the definition of string to fixed-length character, the ICE goes away. So, besides the fact that an ICE usually implies compiler bug, is the code invalid?

[fortran]module some_module

    implicit none
    private
    save

contains

    function some_function(arg) result(status)
        logical :: status
        character(*), intent(IN) :: arg
        integer :: i
        character(:), allocatable :: string

    continue
        status = .FALSE.
        string = TRIM(arg)
        i = LEN_TRIM(string) / 2
        i = MERGE(0, i, some_verification(ADJUSTL(string(:i-1)), 'PARAMETER'))
        status = .TRUE.
    end function

    elemental function some_verification(string, val) result(status)
        logical :: status
        character(*), intent(IN) :: string, val
        integer :: lval

    continue
        status = .FALSE.
    end function

end module some_module
[/fortran]

[Paul_Curtis]

The character variable string is not an array, and hence is not properly allocatable; only arrays are allocatable. Also, the attempt at implicit allocation simply by assigning string as the TRIM() of another character variable is poor practice.

[IanH]

Fortran 2003 introduced allocatable scalars, deferred length character variables and implicit allocation on assignment. What's good and bad practice is a often a matter of taste, but use of these three features in concert strikes me as being an eminently reasonable way to do string handling in the modern form of the language.

[TimP]

Implicit allocation is not enabled by default in ifort. If you intend to use it, you must set /assume:realloc_lhs
Ideally, you would get a clearer error message about this, if that is among your problems.

[John4]

@Paul Curtis: The Fortran 2003 standard added allocatable-length characters to the language (i.e., the LEN part of the character declaration is what's allocatable). And although this discussion is not about coding practices, I agree with you that for assignment to fixed-length characters, ADJUSTL is a better option than TRIM.

@tim18: In IVF, Implicit allocation for allocatable-length character variables (and derived types components, I guess) is independent of the /assume:realloc_lhs flag.

I just wanted to report the ICE/bug, since the forum search didn't return anything related... And also, I wanted to know of any constraints in regards to ELEMENTAL procedures and allocatable-length character variables (but I guess I'll just ask somewhere else about this).

I've found the same sort of ICE throughout some of my code, in previous versions of IVF (especially with allocatable-length character results), but, until now, I could never find a short way to reproduce it (so I usually just changed the ELEMENTAL keyword to PURE).

[Steven_L_Intel1]

John is correct - the /assume:realloc_lhs option is not required for deferred-length character variables. I can reproduce the ICE and will escalate it - thanks for the nice example. I was able to simplify it a bit further to eliminate the MERGE, but the ADJUSTL call is required. Issue ID is DPD200154603.

[Steven_L_Intel1 · Accepted solution]

This issue has been fixed in the compiler sources. The fix should appear in the next major release, planned for late this year.