Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Possible compiler bug: Error #7977 when using auto-generated modules

ereisch
New Contributor II
606 Views

 

TYPE(FOO) FUNCTION FOO_FCN() BIND(C) RESULT(BAR)
  IMPLICIT NONE
  BAR.A = 1
  BAR.B = 2
  RETURN
END FUNCTION

 

SUBROUTINE SOMETHING()
  IMPLICIT NONE
  INTERFACE
    SUBROUTINE SOMETHING_ELSE( ARG ) BIND(C)
      IMPLICIT NONE
      TYPE(FOO), INTENT(IN) :: ARG
    END SUBROUTINE
  END INTERFACE
  TYPE(FOO) FOO_FCN

  CALL SOMETHING_ELSE( FOO_FCN() )

END SUBROUTINE

When attempting something similar to the above and using auto-generated interface files, I always seem to get "error #7977: The type of the function reference does not match the type of the function definition."  Is something I'm doing illegal here, or is something awry in the compiler's argument-checking logic?  I've found that sometimes replacing the TYPE(FOO) FOO_FCN with a full interface specification can occasionally make the problem go away.  Sometimes it doesn't.

I've also found if I replace "CALL SOMETHING_ELSE( FOO_FCN() )" with:

TYPE(FOO) TMP_VAR
TMP_VAR = FOO_FCN()
CALL SOMETHING_ELSE( TMP_VAR )

...the problem also goes away.

I'm using ifort version 2021.4.0.  Compile arguments:

ifort -fpp -no-save-temps -extend-source 132 -assume nounderscore -assume nobscc -align dcommons -zero -sox -warn noalignments,general,ignore_loc,truncated_source,uncalled,usage -c -fp-stack-check -ccdefault fortran -traceback -no-global-hoist -mssse3 -fimf-arch-consistency=true -fimf-precision=high -no-fma -prec-div -fp-speculation=strict -prec-sqrt -fp-model strict -fp-model source -fpe0 -assume protect-parens -fexceptions -g -debug full -debug-parameters -check bounds -gdwarf-3 -warn interfaces -O0 -m32

 

0 Kudos
7 Replies
Steve_Lionel
Honored Contributor III
595 Views

Please provide a complete, reproducible, actual example, not fragments of "something similar". I will mention that the auto-generated .f90 files are merely for reference and not intended for use directly. The .__genmod files should be correct.

0 Kudos
ereisch
New Contributor II
565 Views

F_ENGINE_PARMS.TEXT:

TYPE, BIND(C) :: F_ENGINE_PARMS
	INTEGER*4	A
	INTEGER*4	B
	INTEGER*4	C
	INTEGER*4	D
END TYPE F_ENGINE_PARMS

load_f_engine_parms.for:

        TYPE(F_ENGINE_PARMS) FUNCTION LOAD_F_ENGINE_PARMS() BIND(C) RESULT(PARMS)

        IMPLICIT NONE
#include                "F_ENGINE_PARMS.TEXT"

        PARMS.A = 1
        PARMS.B = 2
        PARMS.C = 3
        PARMS.D = 4

        RETURN
        END FUNCTION

setup_engine.for:

	SUBROUTINE SETUP_ENGINE()

	IMPLICIT NONE
#include		"F_ENGINE_PARMS.TEXT"

	TYPE(F_ENGINE_PARMS) LOAD_F_ENGINE_PARMS
	TYPE(F_ENGINE_PARMS) FOO

	FOO = LOAD_F_ENGINE_PARMS()

	END SUBROUTINE
~/tmp$ ifort -fpp -no-save-temps -extend-source 132 -assume nounderscore -assume nobscc -align dcommons -zero -sox -warn noalignments,general,ignore_loc,truncated_source,uncalled,usage -c -fp-stack-check -ccdefault fortran -traceback -no-global-hoist -mssse3 -fimf-arch-consistency=true -fimf-precision=high -no-fma -prec-div -fp-speculation=strict -prec-sqrt -fp-model strict -fp-model source -fpe0 -assume protect-parens -gen-interfaces nosource -fexceptions -g -debug full -debug-parameters -check bounds -gdwarf-3 -warn interfaces -O0 -I. -m32 load_f_engine_parms.for
~/tmp$ ifort -fpp -no-save-temps -extend-source 132 -assume nounderscore -assume nobscc -align dcommons -zero -sox -warn noalignments,general,ignore_loc,truncated_source,uncalled,usage -c -fp-stack-check -ccdefault fortran -traceback -no-global-hoist -mssse3 -fimf-arch-consistency=true -fimf-precision=high -no-fma -prec-div -fp-speculation=strict -prec-sqrt -fp-model strict -fp-model source -fpe0 -assume protect-parens -nogen-interfaces -fexceptions -g -debug full -debug-parameters -check bounds -gdwarf-3 -warn interfaces -O0 -I. -m32 setup_engine.for

setup_engine.for(9): error #7977: The type of the function reference does not match the type of the function definition.   [LOAD_F_ENGINE_PARMS]
	FOO = LOAD_F_ENGINE_PARMS()
^
compilation aborted for setup_engine.for (code 1)

Note an important difference between the two compile commands: the second requires "-nogen-interfaces"....if it is set to "-gen-interfaces", then the error does not appear.  As I was narrowing it down to a smaller reproducer, it became more evident that this is probably a compiler bug.

0 Kudos
Steve_Lionel
Honored Contributor III
559 Views

I can't reproduce the error you report, but I am seeing a bizarre parsing error that I do not understand.

 

load_f_engine_parms.for(1): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: (
         TYPE(F_ENGINE_PARMS) FUNCTION LOAD_F_ENGINE_PARMS() BIND(C) RESULT(PARMS)
----------------------------------------------------------------------------------^

Odder is that the error goes away if I copy and paste parts of statements.

0 Kudos
ereisch
New Contributor II
550 Views

Hmm....I'm not seeing that parse error; however when I re-run the command on your source, I get my error #7977 again (verifying correct transcribing).  It should be noted that I'm running on Linux (and I tried on two different OS builds -- one was on RHEL7 and the other was on Ubuntu 16.04.

This almost smells of an uninitialized variable use somewhere under the hood of the compiler itself.

0 Kudos
andrew_4619
Honored Contributor II
533 Views

Are not the definitions of TYPE F_ENGINE_PARMS in  LOAD_F_ENGINE_PARMS and SETUP_ENGINE() in fact different local entities rather than the same type? I would normally define the type in a module and then USE that wherever needed. But maybe  I am misunderstanding .....

0 Kudos
Steve_Lionel
Honored Contributor III
516 Views

Andrew, regarding your question about different types:

"Two data entities have the same type if they are declared with reference to the same derived-type definition. Data entities also have the same type if they are declared with reference to different derived-type definitions that specify the same type name, all have the SEQUENCE attribute or all have the BIND attribute, have no components with PRIVATE accessibility, and have components that agree in order, name, and attributes. Otherwise, they are of different derived types."  (F2018 7.5.2.4p2)

Because the types have the BIND attribute, and meet the other requirements, they are considered to be the same type.

0 Kudos
andrew_4619
Honored Contributor II
531 Views

This compiles with no errors. Note also that the "." notation for derived types  is not Fortran  "%" is. The dot is a Intel supported language extension and I would not recommend using it. Also for simple assignment like in your example the default constructor could be used foo = F_Engine_Parms(1,2,3,4) without writing a specific constructor function.

 

module Engine_types
    TYPE, BIND(C) :: F_ENGINE_PARMS
        INTEGER(4) :: A
        INTEGER(4) :: B
        INTEGER(4) :: C
        INTEGER(4) :: D
    END TYPE F_ENGINE_PARMS
end module Engine_types

TYPE(F_ENGINE_PARMS) FUNCTION LOAD_F_ENGINE_PARMS() BIND(C) RESULT(PARMS)
    use Engine_types
    IMPLICIT NONE
    PARMS%A = 1
    PARMS%B = 2
    PARMS%C = 3
    PARMS%D = 4
END FUNCTION

SUBROUTINE SETUP_ENGINE()
    use Engine_types
    IMPLICIT NONE
    TYPE(F_ENGINE_PARMS), external :: LOAD_F_ENGINE_PARMS
    TYPE(F_ENGINE_PARMS):: FOO
    FOO = LOAD_F_ENGINE_PARMS()
END SUBROUTINE

 

 

0 Kudos
Reply