Polymorphic + optional arguments - compiler bug?

Polymorphic + optional arguments - compiler bug?

Hello,
I have encountered following rather nasty issue when dealing with polymorphic dummy arguments. The subroutine below simply accepts one polymorphic argument and several additional optional arguments. However, the behavior of the resulting program compiled (-O0) with:
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.1.2.273 Build 20111128
is somewhat strange since the output is just "msg = ", i.e., the presence of one of the optional arguments is correctly recognized, nevertheless its value disappeared in a puff of smoke...

On the other hand, slightly newer version
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.1.117 Build 20121010
produces the expected result...

Any ideas/suggestions how to force the older version to conform to the correct behavior? For example changing the order of the dummy arguments option_char and option_long_name (on line 9) leads to an even worse outcome, namely:

 msg =
 resetmsg = FOR_DUMP_EXCEPTION_INFOfor_init.cLinux
Dump of siginfo st
 ruct:
Dump of ucontext struct:
FOR_IGNORE_EXCEPTIONSsegmentation fault

PROGRAM test
    INTEGER, PARAMETER :: dp = KIND(1D0)
    INTEGER, PARAMETER :: ERROR_OK = 0
    LOGICAL :: flag
    CHARACTER(LEN=512) :: msg
    flag = LoadValue(msg, option_long_name = 'reset')
    WRITE(*, *) "msg = ", TRIM(msg)
CONTAINS
LOGICAL FUNCTION LoadValue(val, option_char, option_long_name, err_val) RESULT(ret)
    CLASS(*), INTENT(INOUT) :: val
    CHARACTER, INTENT(IN), OPTIONAL :: option_char
    CHARACTER(LEN=*), INTENT(IN), OPTIONAL :: option_long_name
    INTEGER, INTENT(INOUT), OPTIONAL :: err_val
    IF(PRESENT(err_val)) err_val = ERROR_OK
    SELECT TYPE(val)
        TYPE IS(INTEGER)
            val = 0
        TYPE IS(REAL(dp))
            val = 0
        TYPE IS(CHARACTER(*))
            val = "N/A"
            IF(PRESENT(option_long_name)) val = TRIM(option_long_name)
    END SELECT
    ret = .TRUE.
END FUNCTION
END PROGRAM

Thanks,
M.

M.
5 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

I've tested your example on ifort version 14.0.0 and I've got the correct output, that is:

ifort main.f90 ; ./a.out 
 msg = reset

As you found, a bug that was in 12.1 was fixed in 13.0. I'm not aware of a way to force the now--two-year-old version to do what you want. Please upgrade to the current version.

Steve - Intel Developer Support

Well, you are right that this bug might seem irrelevant since it has been fixed in the newer release, nevertheless I believe that its exposure can be still useful for someone since it is IMHO not so uncommon to encounter ifort 12.1 on many HPC clusters. It took me quite a non-negligible time to locate it...

M.

By the way, I suppose that one of the workarounds (in order to specialize LoadValue for several types) could consist in using an interface with several module procedures instead of the polymorphism technique, although it leads to code duplication...

M.

Lascia un commento

Eseguire l'accesso per aggiungere un commento. Non siete membri? Iscriviti oggi