wrong/strange error message with ifort 11.1.064

[Hans_Peschke]

Hi,

the following Code results wrongly in a in my opinion wrong error message, but decide self:

Code:

[plain]module ifort_error_res
implicit none

abstract interface
  function iface_B() result(res)
    real :: res
  end function iface_B
end interface

contains

  function fun1(B) result(res)
    procedure(iface_B) :: B
    real               :: res

    res = 0.0
  end function fun1

  ! res || re
  function fun2() result(res)
    real :: res

    res = 0.0
  end function fun2
end module ifort_error_res

program test
! use...
implicit none

write(*,*) 'works'

end program test[/plain]

I filtered this code out of an program with a few hundred loc's.

Compiler message:

[plain]$ ifort ifort_error_res.f90
ifort_error_res.f90(21): error #6418: This name has already been assigned a data type.   [RES]
    real :: res
------------^
compilation aborted for ifort_error_res.f90 (code 1)
$
[/plain]

I remember, that the original code fails with "code 3", dont know what this means.

Compiled with ifort 11.1.064 on Ubuntu 9.10:

[plain]$ ifort -logo
Intel Fortran Compiler Professional for applications running on IA-32, Version 11.1    Build 20091130 Package ID: l_cprof_p_11.1.064
Copyright (C) 1985-2009 Intel Corporation.  All rights reserved.
[/plain]

Thanks in advance

Hans Peschke

[Steven_L_Intel1]

Thanks - I can reproduce the problem. The workaround is to change the name of "res" in the abstract interface or in fun1, though you may have already figured this out. You can also avoid the error by reversing the order of the functions so that fun2 comes first. Based on my observations, I think that the processing of procedure(iface_B) in fun1 is corrupting the compiler's symbol table information for the identifier "res".

I will report this to the developers - thanks for bringing it to our attention and for providing such a nice test case. The issue ID is DPD200148932.

"Code 3" is usually an internal compiler error. If you could provide the sources for that as well (a gzipped tar file would be fine), that would be appreciated.

[Kevin_D_Intel]

Quoting - Steve Lionel (Intel)

"Code 3" is usually an internal compiler error. If you could provide the sources for that as well (a gzipped tar file would be fine), that would be appreciated.

I believe this relates to Han's other post (here) which contains the requested test case which I confirmed and reported to Development.

[Hans_Peschke]

Quoting - Kevin Davis (Intel)

I believe this relates to Han's other post (here) which contains the requested test case which I confirmed and reported to Development.

Thats right. I mixxed it up a little bit.

First, both compiler-error producing code snippets are originally from the same project. I had to separate both problems out of the whole code tree.

I verified, with the snippets and the original code, that:
"code 3" only appears in the code resulting in the catastrophic error in the other thread.
"code 1" appears only in the code above.

Thank you Kevin and Steve

[Steven_L_Intel1]

The problem described in this thread (error 6418 inappropriately given) is fixed in our sources. I think that the fix will appear in Update 5, scheduled for mid-February. I'll reply here when the fix is available.