gfortran and C interoperability problem
in [Fortran]
|
Prev: f2003 compilers?
Next: error - what is unit 9001
From: steve on 12 Jan 2010 19:38 On Jan 12, 4:08 pm, nos...(a)see.signature (Richard Maine) wrote: > steve <kar...(a)comcast.net> wrote: > > On Jan 12, 2:54 pm, "M.S. Breitenfeld" <msbrtn...(a)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
From: Scot on 12 Jan 2010 20:55 I should have mentioned that I too tried it with TYPE, BIND(C) :: myftype with out any luck for any of the flavors of gfortran. On Jan 12, 5:13 pm, Reinhold Bader <Ba...(a)lrz.de> wrote: > Hello, > > 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 > > > > > 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 > >
From: M.S. Breitenfeld on 13 Jan 2010 12:30 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 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. On 01/12/2010 04:54 PM, M.S. Breitenfeld 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 > > 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
From: Reinhold Bader on 13 Jan 2010 13:18 Am 13.01.2010 18:30, schrieb M.S. Breitenfeld: > 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 > > > On 01/12/2010 04:54 PM, M.S. Breitenfeld 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 >> >> 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 >
From: Richard Maine on 13 Jan 2010 16:47
M.S. Breitenfeld <msbrtnfld(a)gmail.com> wrote: > 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." -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |