- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page