I'm trying to interface gsl to a fortran program. Thus, I have
written :
interface
integer(c_int) function gsl_sf_lngamma_sgn_e_wrapper(X, &
RESULTAT, SIGNE) bind(C, name='gsl_sf_lngamma_sgn_e_wrapper')
use iso_c_binding
implicit none
type, bind(C) :: GSL_SF_RESULT
real(c_double) VALEUR
real(c_double) ERREUR
end type
real(c_double), intent(in) :: X
type(GSL_SF_RESULT), intent(out) :: RESULTAT
real(c_double), intent(out) :: SIGNE
end function
end interface
gfortran (gcc version 4.3.3 (Debian 4.3.3-14)) returns :
fonctions_speciales.conv.F90:51.24:
RESULTAT, SIGNE) bind(C, name='gsl_sf_lngamma_sgn_e_wrapper')
1
Error: Type 'resultat' at (1) is a parameter to the BIND(C) procedure
'gsl_sf_lngamma_sgn_e_wrapper' but is not C interoperable because
derived type 'gsl_sf_result' is not C interoperable
If I write :
type GSL_SF_RESULT
sequence
real(c_double) VALEUR
real(c_double) ERREUR
end type
this code can be successfull compiled. I don't understand why
GSL_SF_RESULT is not C interoperable... Any explanation ?
Thanks in advance,
JKB
I think your code is correct and gfortran has a bug in its C interop
implementation. FWIW, three other compilers do not fail to compile
the interface.
Note that changing from a BIND(C) to a sequence type formally makes
the type non-interoperable. The resulting illegal code should normally
also be diagnosed by the compiler.
Regards
Reinhold
JKB schrieb:
Thanks a lot,
I shall test with the last gcc snapshot and do a bug report if bug
is present.
Regards,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
I agree that gfortran has a bug.
> > Note that changing from a BIND(C) to a sequence type formally makes
> > the type non-interoperable. The resulting illegal code should normally
> > also be diagnosed by the compiler.
I agree also with that comment. I actually have already filled a bug,
cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40920, and spend some
time finding out what goes wrong - albeit without finding the problem.
As a work around: If one moves the type declaration out of the
INTERFACE and imports the type, it works correctly. (Rejecting
SEQUENCE, allowing BIND(C).) Some resolving function call is not
called before the check is done - the question is only were it is
missing.
Thanks for reporting the bug (here - plus for planing to fill a report
in bugzilla)!
Tobias
PS: Somehow it takes a while to shake out all bugs in the BIND(C)
support - at least I have seen quite a few BIND(C) bugs in several
compilers, though it is fortunately increasingly harder to find one.
Still a remark by some computer science student, who did an internship
in a numerical physics group, is unfortunately true in my opinion: If
something does not work, the chance that it is a compiler bug can not
be ruled out; by contrast, finding a compiler bug in C is much harder.
(To a certain extend it has also something to do with the larger
number of Fortran compilers being used compared to a more limited
number of C compilers and the larger user base of C.)
There are many difficult to implement, at least relative to more
C features, in Fortran 2003. C interoperability especially
requires a detailed understanding of both Fortran and C to work
through finding and fixing bugs.
-- glen
Did he mean as a compiler writer, or a support person? If the latter,
I agree with him.
>> (To a certain extend it has also something to do with the larger
>> number of Fortran compilers being used compared to a more limited
>> number of C compilers and the larger user base of C.)
Grrk. The first is very out of date - like 15 years! There are
almost certainly many more C than Fortran compilers nowadays - perhaps
even ten times as many. Of course, many of those are used only on
'specialist' systems.
>There are many difficult to implement, at least relative to more
>C features, in Fortran 2003. C interoperability especially
>requires a detailed understanding of both Fortran and C to work
>through finding and fixing bugs.
Or even to work out when a feature is a bug :-(
Regards,
Nick Maclaren.
Well, also C89 vs. C99. C89 is simple enough (compared to F2003),
and been around long enough, that the remaining compiler bugs might
be reasonably hard to find.
<>> (To a certain extend it has also something to do with the larger
<>> number of Fortran compilers being used compared to a more limited
<>> number of C compilers and the larger user base of C.)
< Grrk. The first is very out of date - like 15 years! There are
< almost certainly many more C than Fortran compilers nowadays - perhaps
< even ten times as many. Of course, many of those are used only on
< 'specialist' systems.
Probably you should weight by usage. The chance of finding a bug
in a compiler depends on how much it is used. (and how it is used.)
I used to be pretty good at finding bugs in programs, trying features
in ways that might not have been expected. If you weight each
compiler by the fraction of people that use it, I probably agree
that you get a larger total for Fortran. That is, in biology terms,
there is more genetic diversity in Fortran compilers.
<>There are many difficult to implement, at least relative to more
<>C features, in Fortran 2003. C interoperability especially
<>requires a detailed understanding of both Fortran and C to work
<>through finding and fixing bugs.
< Or even to work out when a feature is a bug :-(
I think that is part of what I was trying to say, but didn't
think of the words at the time.
-- glen
Don't bet on it - if it WERE simple, that might be the case :-(
>Probably you should weight by usage. The chance of finding a bug
>in a compiler depends on how much it is used. (and how it is used.)
>I used to be pretty good at finding bugs in programs, trying features
>in ways that might not have been expected. If you weight each
>compiler by the fraction of people that use it, I probably agree
>that you get a larger total for Fortran. That is, in biology terms,
>there is more genetic diversity in Fortran compilers.
I am sure that I don't understand you, but you have made two (entirely
separate) good points! I am not sure they were the two you intended,
of course :-)
I agree that C compiler writers copy each other more, and C programmers
are more likely to use only a single compiler. One of the reasons
that I have hit problems with the C standard that are strongly denied
by its supporters is that I have both designed a run-time system for
an "outfield" system and have experience with C on a range of other
"outfield" systems (as well as mainstream systems). That is fairly
true of SC22WG5, but not at all true of SC22WG14 (or even SC22WG21).
Regards,
Nick Maclaren.