gfortran and C interoperability problem
M.S. Breitenfeld
suns,and pgi compilers. But it fails with gfortran 4.3,4.4,4.5.It gives
the error:
FUNCTION test_genprop_cls_cb1_f(create_data) bind(C)
1
Error: Type 'create_data' at (1) is a parameter to the BIND(C)
procedure 'test_genprop_cls_cb1_f' but is not C interoperable because
derived type 'myftype' is not C interoperable
MODULE test_genprop_cls_cb1_mod
! Callback subroutine
IMPLICIT NONE
CONTAINS
FUNCTION test_genprop_cls_cb1_f(create_data) bind(C)
USE ISO_C_BINDING
IMPLICIT NONE
INTEGER(C_INT) :: test_genprop_cls_cb1_f
TYPE :: myftype
INTEGER(C_INT) :: count
INTEGER(C_INT) :: id
END TYPE myftype
TYPE(myftype) :: create_data
test_genprop_cls_cb1_f = 1
END FUNCTION test_genprop_cls_cb1_f
END MODULE test_genprop_cls_cb1_mod
PROGRAM main
END PROGRAM main
steve
> I have this extracted test program that compiles with intel, g95,
> suns,and pgi compilers. But it fails with gfortran 4.3,4.4,4.5.It gives
> the error:
>
> FUNCTION test_genprop_cls_cb1_f(create_data) bind(C)
> 1
> Error: Type 'create_data' at (1) is a parameter to the BIND(C)
> procedure 'test_genprop_cls_cb1_f' but is not C interoperable because
> derived type 'myftype' is not C interoperable
Reinhold Bader
Am 12.01.2010 23:54, schrieb M.S. Breitenfeld:
> I have this extracted test program that compiles with intel, g95,
> suns,and pgi compilers. But it fails with gfortran 4.3,4.4,4.5.It gives
> the error:
>
> FUNCTION test_genprop_cls_cb1_f(create_data) bind(C)
> 1
> Error: Type 'create_data' at (1) is a parameter to the BIND(C)
> procedure 'test_genprop_cls_cb1_f' but is not C interoperable because
> derived type 'myftype' is not C interoperable
Well, the error message describes the issue with the code pretty well -
the standard's prescription for all C-interoperable procedure indeed is
that all dummy arguments must be interoperable. An entity of derived type is
interoperable only if the type definition includes a BIND(C) as follows:
TYPE, BIND(C) :: myftype
INTEGER(C_INT) :: count
INTEGER(C_INT) :: id
END TYPE myftype
(and of course all type components must then be interoperable in turn).
This by the way does not necessarily imply that it isn't possible to
deal somehow with non-interoperable entities. It does however mean that
some extra effort will be needed - for example by using type(c_ptr) entities
and the c_loc() intrinsic to generate *void C pointers, effectively creating a
handle to your non-interoperable entity which can be passed through C
code.
Regards
Reinhold
Reinhold Bader
I see: gfortran is buggy in that it also rejects the corrected version of
OP's code. This doesn't change the fact that OP's code is not conforming.
Regards
Reinhold
Richard Maine
Perhaps I am misreading something, but that bug report doesn't sound
like the OP's problem. That bug report says it is about rejecting valid
code, where the derived type in question is interoperable.
The OP's code, on the other hand, is not valid. It is not a compiler bug
to reject it. I would say more the opposite - that it would be a
compiler bug to fail to diagnose it.
As Reinhold notes, the cited error message seems pretty much on
target... well... except for some pretty big terminology errors now that
I look at it more closely.
The biggest terminology error is that it refers to create_data as a
type, which just isn't so at all. I could well imagine that confusing
people. There is a problem with the type of create_data, but create_data
is not itself a type.
The second terminology error is in referring to actual arguments as
parameters. The compiler migt be written in C, but it is a compiler for
the Fortran language. Its error messages ought to use correct Fortran
terminology. There are things in Fortran called parameters; this isn't
one of those.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
steve
> steve <kar...@comcast.net> wrote:
> > On Jan 12, 2:54 pm, "M.S. Breitenfeld" <msbrtn...@gmail.com> wrote:
> > > I have this extracted test program that compiles with intel, g95,
> > > suns,and pgi compilers. But it fails with gfortran 4.3,4.4,4.5.It gives
> > > the error:
>
> > > FUNCTION test_genprop_cls_cb1_f(create_data) bind(C)
> > > 1
> > > Error: Type 'create_data' at (1) is a parameter to the BIND(C)
> > > procedure 'test_genprop_cls_cb1_f' but is not C interoperable because
> > > derived type 'myftype' is not C interoperable
>
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40920
>
> Perhaps I am misreading something, but that bug report doesn't sound
> like the OP's problem. That bug report says it is about rejecting valid
> code, where the derived type in question is interoperable.
>
> The OP's code, on the other hand, is not valid. It is not a compiler bug
> to reject it. I would say more the opposite - that it would be a
> compiler bug to fail to diagnose it.
Yes, I missed the missing BIND(C) in the OP's derived type. His code
is
related to the gfortran bug report in that when the bug is fixed, this
code still needs to be rejected.
> As Reinhold notes, the cited error message seems pretty much on
> target... well... except for some pretty big terminology errors now that
> I look at it more closely.
>
> The biggest terminology error is that it refers to create_data as a
> type, which just isn't so at all. I could well imagine that confusing
> people. There is a problem with the type of create_data, but create_data
> is not itself a type.
Definitely! I was scratching my head when I threw the code at
gfortran 4.5.
I'll update the gfortran bug report to note the error message needs
some TLC.
> The second terminology error is in referring to actual arguments as
> parameters. The compiler migt be written in C, but it is a compiler for
> the Fortran language. Its error messages ought to use correct Fortran
> terminology. There are things in Fortran called parameters; this isn't
> one of those.
Yep, I noticed that one too. If I had to guess, based on your many
posts
here, this is probably in your top-5 for terminology abuse.
--
steve
Scot
myftype with out any luck for any of the flavors of gfortran.
M.S. Breitenfeld
compiler and the -e03 flag (issue errors for language elements that are
not standard in Fortran 2003) it gives no warning.
In the past when I ask about such things their response has been that
diagnosis of this is not required by the standard,as the rule being
violated is neither a numbered syntax rule nor a constraint. So it is
the requirement on the programmer to comply with the stated rule.
Which is probably the situation in this case.
I have yet to find a compiler that does not compile the original code
from any vender except gfortran. So what is the thinking in gfortran to
not issue a warning instead of an error in this cause. When does the
standard dictate that a coding mistake is a fatal error and not a
warning, or is that left up to the vendor.
Reinhold Bader
> My general question is this then, when I compile the code with the intel
> compiler and the -e03 flag (issue errors for language elements that are
> not standard in Fortran 2003) it gives no warning.
In my opinion, this is a bug in the very many implementations which do
not flag this as an error. Constraint C1238 of the Fortran 2003 standard
deals with the situation you have here.
> In the past when I ask about such things their response has been that
> diagnosis of this is not required by the standard,as the rule being
> violated is neither a numbered syntax rule nor a constraint. So it is
> the requirement on the programmer to comply with the stated rule.
> Which is probably the situation in this case.
Absolutely not, see above.
> I have yet to find a compiler that does not compile the original code
> from any vender except gfortran. So what is the thinking in gfortran to
> not issue a warning instead of an error in this cause.
> When does the
> standard dictate that a coding mistake is a fatal error and not a
> warning, or is that left up to the vendor.
In the cases where a violated requirement is covered neither by syntax rule nor
constraint, you are right that the processor may not (be able to) diagnose
the violation at compile time. The behaviour of the resulting executable
will in any case be implementation dependent.
In this case it is also allowed that a processor might accept non-conforming
code as an extension. However if standard-conformnance is enforced via a
switch and the processor is capable of diagnosing the issue, then it must
refuse to accept the code.
Regards
Reinhold
Richard Maine
> In the past when I ask about such things their response has been that
> diagnosis of this is not required by the standard,as the rule being
> violated is neither a numbered syntax rule nor a constraint. So it is
> the requirement on the programmer to comply with the stated rule.
> Which is probably the situation in this case.
No. You can't validly generalize to "such things". Yes, there are many
"such things" where the standard doesn't require diagnosis; for some
errors, diagnosis of all cases would be impractical (which is often why
the standard doesn't require it). You have to actually point to a
specific requirement in order to correctly claim nonconformance to the
standard. But in *THIS* case, there *IS* such a specific requirement.
Yes, the rule being violated is a constraint. As Reinhold noted, the
constaint in question is C1238. If your other cases don't likewise
violate a constraint, then they aren't sufficiently "such cases" to be
comparable.
Now what I'd half expect as a further reply from some vendors is that
the current compilers don't claim conformance with f2003. That gets back
to my "favorite" standards pet peeve of these days - the difference
between claiming conformance to a version of the standard versus
claiming to have implemented a list of features. A standard is more than
just a list of features. (And yes, you can expect me to point this out
more than once again in the future, since the message doesn't really
seem to get across to... um.... some people whom I'd like to get it.)
Sure, no compiler ever has been in perfect conformance with any version
of the standard; they all have bugs. (Yes, I know that a regular poster
here claims otherwise for his preferred compiler choice, but I'll ignore
that). But the standard at least gives a basis for evaluation (some
might even say a "standard"). When you point to a failure to conform to
the standard, that counts as a bug. When a vendor just says that they
implement "the F2003 C interop features", you don't have a solid basis
for claiming that failings like this are a bug, because nothing
definitively specifies that diagnosis of constraint violations has to
count as a "C interop feature."