Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Type, bind(c) and gfortran

10 views
Skip to first unread message

JKB

unread,
Jul 30, 2009, 1:03:05 PM7/30/09
to
Hello,

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

Reinhold Bader

unread,
Aug 5, 2009, 9:27:59 AM8/5/09
to
Hello,

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:

JKB

unread,
Aug 5, 2009, 10:39:11 AM8/5/09
to
Le 05-08-2009, ? propos de
Re: Type, bind(c) and gfortran,
Reinhold Bader ?crivait dans comp.lang.fortran :

> Hello,
>
> 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.


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.

Tobias Burnus

unread,
Aug 5, 2009, 12:26:53 PM8/5/09
to
On 5 Aug., 10:39, JKB <knatsc...@koenigsberg.fr> wrote:
> >     I think your code is correct and gfortran has a bug in its C interop
> >     implementation.

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.)

glen herrmannsfeldt

unread,
Aug 5, 2009, 1:10:01 PM8/5/09
to
Tobias Burnus <bur...@net-b.de> wrote:
(snip)


> 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

nm...@cam.ac.uk

unread,
Aug 5, 2009, 1:24:37 PM8/5/09
to
In article <h5ced9$jgn$1...@naig.caltech.edu>,
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

>Tobias Burnus <bur...@net-b.de> wrote:
>
>> 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.

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.

glen herrmannsfeldt

unread,
Aug 5, 2009, 2:28:07 PM8/5/09
to
nm...@cam.ac.uk wrote:
< In article <h5ced9$jgn$1...@naig.caltech.edu>,
< glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
<>Tobias Burnus <bur...@net-b.de> wrote:

<>> 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.

< Did he mean as a compiler writer, or a support person? If the latter,
< I agree with him.

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

nm...@cam.ac.uk

unread,
Aug 5, 2009, 4:01:41 PM8/5/09
to
In article <h5civn$jgn$6...@naig.caltech.edu>,

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>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.

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.

0 new messages