Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
27160 Discussions

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

ereisch
Novice
266 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
Black Belt Retired Employee
255 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.

ereisch
Novice
225 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.

Steve_Lionel
Black Belt Retired Employee
219 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.

ereisch
Novice
210 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.

andrew_4619
Honored Contributor I
193 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 .....

Steve_Lionel
Black Belt Retired Employee
176 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.

andrew_4619
Honored Contributor I
191 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

 

 

Reply