New version, old bug

[John4]

Hi, with the code below, and the "-check pointers" option, I get a runtime error (Attempt to use pointer S1 when it is not associated with a target) when using ifort 12.1. With ifort 12.0.5 there's no error at all and the program runs just fine.

To the best of my knowledge, the code is OK, so it seems like the new version of the compiler reintroduced an old bug related to the class keyword.

[fortran]module mod1
    implicit none
    private
    save

    type, public :: t1
        character(:), allocatable :: chars
    end type

    interface assignment(=)
        module procedure    ASSIGN_t1_chars
    end interface;  public assignment(=)

contains
    elemental subroutine ASSIGN_t1_chars(S1, C2) 
        class(t1), intent(OUT) :: S1
        character(*), intent(IN)  :: C2
        S1%chars = C2
    end subroutine
end module mod1

module mod2
    use mod1

    implicit none
    private
    save

    public  getCmdArgs

contains
    subroutine getCmdArgs (cmd) !result(status)
        type(t1), allocatable, intent(OUT) :: cmd(:)
        integer :: i, istat, nargs
        character(2047) :: buffer

        nargs = COMMAND_ARGUMENT_COUNT()
        allocate (cmd(0:nargs), STAT = istat)
        if (istat /= 0) stop

        do i = 0, nargs
            call GET_COMMAND_ARGUMENT(i, buffer, STATUS = istat)
            if (istat /= 0) stop
            cmd(i) = TRIM(ADJUSTL(buffer))
        enddo
    end subroutine
end module mod2

use mod1
use mod2

implicit none

integer :: i
type(t1), allocatable :: cmd(:)

call getCmdArgs(cmd)
print '((A))', (cmd(i)%chars, i = 0, UBOUND(cmd, 1))
end
[/fortran]

[Steven_L_Intel1]

Thanks - we'll take a look.

[Udit_P_Intel]

I think Steve can comment better on this, but I found that in the ASSIGN_t1_chars() subroutine, changing intent(OUT) on S1 to intent(INOUT) makes the program run fine.

From my knowledge of polymorphic intent(out) dummy arguments, they should be deallocated upon entry to a subroutine. Here is the excerpt from Fortran 2003 standard, P 116:

9 When a procedure is invoked, any allocated allocatable object that is an actual argument associated with
10 an INTENT(OUT) allocatable dummy argument is deallocated; any allocated allocatable object that is
11 a subobject of an actual argument associated with an INTENT(OUT) dummy argument is deallocated.

In the main program, cmd is declared allocatable, which may be why we are deallocating S1 upon entry to ASSIGN_t1_chars() and is caught by /check:pointer.

I know this automatic deallocation is a recent feature that was implemented in a recent release.

Best!
-Udit

[Steven_L_Intel1]

Well, yes and no. Udit is correct in saying that any allocatable components of S1 are deallocated on entry to the defined assignment procedure. However, the component being a deferred-length character allocatable, it should be automatically (re)allocated on assignment. (We do not require the use of /assume:realloc_lhs for this case.) I think we have an open issue on this but I will have to check when I get to the office in the morning.

[John4]

The actual argument to S1 is not an allocatable variable. It is a component of cmd, which is indeed an allocatable array, but the ASSIGN_t1_chars subroutine doesn't need to know or rely on that information ---and in fact, it cannot.

The issue here is that there seems to be something wrong with ifort's passing mechanism when it comes to the class keyword (since changing it to type makes the code work just fine). I remember a similar bug, already solved, in which the substring of a deferred-length character variable was not being passed correctly, but there were no issues with an equivalent substring of a fixed-length character variable.

Also, if I recall correctly, the actual code to this particular sample (i.e., a replacement for the iso_varying_string module) didn't work with the first version of ifort that had both the deferred-length character and the class features, but that was fixed in latter updates and the code runs just fine with ifort 12.0.5. So it seems like a regression to me.

[Udit_P_Intel]

Aah, now I see. Thanks for pointing that out. We will take a look.
Best!
-Udit

[Steven_L_Intel1]

I can see that a similar-looking bug from here was indeed fixed for 12.1, but sometimes a different test program reveals a different issue.

[Steven_L_Intel1]

Ah, the old bug I referenced is a different problem entirely.

I can reproduce this one and also confirm that it worked in Update 5. Issue ID is DPD200173391. Substituting TYPE(T1) for CLASS(T1) is a workaround in this example, but may not be appropriate in all cases.

Can you point to an old thread with this issue? I couldn't find a similar case in our database.

[John4]

Hmmm... I couldn't find it either, so maybe I just thought about reporting it. But I did report this one, which seems to be related.

And the thread you pointed about the use of "USE" for type-bound procedures, is similar to this one.

[Steven_L_Intel1 · Accepted solution]

This will be fixed in Update 8.