Fortran - BIND(C) EXPORT / IMPORT of Fortran variables

Author

BIND(C) EXPORT / IMPORT of Fortran variables

Henrik Holst

2008-03-13, 10:17 pm

Hi!

I have tried to compile the following piece of code:

MODULE GLOBALS
IMPLICIT NONE
INTEGER, BIND(C) :: FOO
END GLOBALS

And I saw some inconsistency (or if I should say variations) between
how different compilers interpret this code.

G95 gave me no symbol named "foo" in the object file. Intel 10 and
Sunstudio 12 gave me a symbol called "foo" (4 byte integer on my x86
32bit platform).

How is this supposed to be interpreted? I have asked about this before
in the G95 forums [1] and they said that G95:s interpretation was
correct. But Intel usually is right in my experience so which one is
it? Is the symbol "foo" supposed to be defined in "globals.o" or not?

[1] http://groups.google.com/group/gg95...34f00877c93eb28

Regards,
--
Henrik Holst, Sweden
http://www.nada.kth.se/~holst/contact.shtml
(Do not send mail to my GMAIL box - I don't use it.)

2008-03-13, 10:17 pm

> And I saw some inconsistency (or if I should say variations) between
> how different compilers interpret this code.

I don't think that's an inconsistency: they produce different object
files, but I'm sure you'd find out that these object files behave exactly
the same in all circumstances.

--
FX

Richard Maine

2008-03-13, 10:17 pm

Henrik Holst <henrikholst80@gmail.com> wrote:

> MODULE GLOBALS
> IMPLICIT NONE
> INTEGER, BIND(C) :: FOO
> END GLOBALS
....
> G95 gave me no symbol named "foo" in the object file. Intel 10 and
> Sunstudio 12 gave me a symbol called "foo" (4 byte integer on my x86
> 32bit platform).
>
> How is this supposed to be interpreted?

Well, for a start, the interpretation involves how code works - not what
appears in object files. I won't try to discuss matters at the level of
what appears in object files. I had to go read the thread cited in order
to figure out what you were talking about.

> [1]
http://groups.google.com/group/gg95...3a3d975144165ff
1/434f00877c93eb28

But on reading that thread, Imust say that I disagree with the
statements in it, in particular the one to the efect that

"The bind(c) on objects relies on storage being defined within
C."

and

"the bind(c) attribute on variables can be used to import C's external
variables, not to export Fortran's."

I see no support in the standard for those statements... and I'm pretty
sure that's because there isn't any such support because that's not what
I recall as the intent. Did the words fail to capture what I recall as
the intent? Let's see... In 15.3 "Interoperation with C global
variables", we have

"There does not have to be an associated C entity for a Fortran
entity with the BIND attribute."

Hard to imagine a more explicit refutation that that.

I don't know the precise translation of the concepts involved into
object file format. As I said above, I won't try to go into that. But I
know there is such a translation, both because plenty of implementors
seemed happy when the material was writen (and yes, I'm pretty sure they
understood that aspect) and because it is much like the concepts
involved in Fortran COMMON. In particular...

There can be at most one place where the BIND(C) variable (or COMMON
block) is initialized. In the case of BIND(C), that place can be in
Fortran or in C, or in neither, but not in both. See 15.3 again

"A variable shall not be initially defined by more than one
processor."

Note that zero is an option. That's what "not...more than one" means.
Both zero and one count as "not more than one". The standard doesn't use
that kind of phrasing to mean "exactly one".

If one of the processors initializes the variable, that will typically
be the "defining" (not the right term, I'm sure) place and the others
will link to it. If neither initializes the variable, then uninitialized
space is defined. As noted above, that's the same way that named COMMON
works in Fortran in that there might or might not be one place that
initializes it, but there can never be more than one.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

2008-03-13, 10:17 pm

> Well, for a start, the interpretation involves how code works - not
> what appears in object files.

I do agree with that, and I've found a way to relate both in that
particular case. Should the following work or not?

$ cat a.f90
module globals
use iso_c_binding
integer(c_int), bind(c) :: foo
end module globals

$ cat a.c
extern int foo;
int main(void){ foo = 0; return 0;}

My tests show that it works with gfortran but doesn't work with g95:

$ gfortran a.f90 a.c && echo Yes
Yes

$ g95 a.f90 a.c && echo Yes
cc1: error: unrecognized command line option "-iprefix"

$ g95 -c a.f90 && gcc a.o a.c && echo Yes
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:
_foo
collect2: ld returned 1 exit status

If I understand correctly what you wrote, and contrarily to my initial
opinion, the codes above are standard-conforming and should compile. This
is thus a bug in g95. Is that right?

--
FX

Richard Maine

2008-03-13, 10:17 pm

FX <coudert@alussinan.org> wrote:

>
> I do agree with that, and I've found a way to relate both in that
> particular case. Should the following work or not?
>
> $ cat a.f90
> module globals
> use iso_c_binding
> integer(c_int), bind(c) :: foo
> end module globals
>
> $ cat a.c
> extern int foo;
> int main(void){ foo = 0; return 0;}

I think so. But my C proficiency is weak on fine points. I can reproduce
the same symptoms by using the following Fortran main program instead of
the C one.

program main
use globals
foo = 42
write (*,*) foo
end

That also fails to link with the g95 version I have installed here (and
it gets the same error message about some foo$non_lazy_ptr. I don't
happen to have gFortran to check. I'm a little suspicious that the
"non_lazy" part might be a hint as to the problem,

> If I understand correctly what you wrote, and contrarily to my initial
> opinion, the codes above are standard-conforming and should compile. This
> is thus a bug in g95. Is that right?

I'd agree.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Craig Powers

2008-03-13, 10:17 pm

Henrik Holst wrote:
> Hi!
>
> I have tried to compile the following piece of code:
>
> MODULE GLOBALS
> IMPLICIT NONE
> INTEGER, BIND(C) :: FOO
> END GLOBALS
>
> And I saw some inconsistency (or if I should say variations) between
> how different compilers interpret this code.
>
> G95 gave me no symbol named "foo" in the object file. Intel 10 and
> Sunstudio 12 gave me a symbol called "foo" (4 byte integer on my x86
> 32bit platform).
>
> How is this supposed to be interpreted? I have asked about this before
> in the G95 forums [1] and they said that G95:s interpretation was
> correct. But Intel usually is right in my experience so which one is
> it? Is the symbol "foo" supposed to be defined in "globals.o" or not?
>
> [1] http://groups.google.com/group/gg95...34f00877c93eb28

I don't think the symbol is required to be named "foo", exactly,
although I'd be a bit surprised to find nothing where "foo" appears as
part of the name.

Arjen Markus

2008-03-14, 4:45 am

On 13 mrt, 22:27, Craig Powers <eni...@hal-pc.org> wrote:

> I don't think the symbol is required to be named "foo", exactly,
> although I'd be a bit surprised to find nothing where "foo" appears as
> part of the name.

I think it is: by default it is the lowercase version of the name of
the Fortran variable (at least if I understand MR&C's Fortran 95/2003
explained correctly).

You can give it a different name via BIND(C, NAME='bar')

Regards,

Arjen

2008-03-14, 4:45 am

>> I don't think the symbol is required to be named "foo", exactly
>
> I think it is: by default it is the lowercase version of the name of
> the Fortran variable

No, the symbols has to have the same name than the C compiler would give
to "foo". Systems have different rules for symbol names, for example
MacOS prefixes them with an underscore:

$ cat a.f90
module globals
use iso_c_binding
integer(c_int), bind(c) :: foo
end module globals
$ gfortran -c a.f90 && nm a.o
00000010 C _foo
$ cat b.c
extern int foo;
int main(void){ foo = 0; return 0;}
$ gcc -c b.c && nm b.o
00000024 S ___i686.get_pc_thunk.cx
U _foo
00000000 T _main

--
FX

Arjen Markus

2008-03-14, 4:45 am

On 14 mrt, 09:37, "FX" <coud...@alussinan.org> wrote:
>
>
> No, the symbols has to have the same name than the C compiler would give
> to "foo". Systems have different rules for symbol names, for example
> MacOS prefixes them with an underscore:
>
> $ cat a.f90
> module globals
> =A0 use iso_c_binding
> =A0 integer(c_int), bind(c) :: foo
> end module globals
> $ gfortran -c a.f90 && nm a.o
> 00000010 C _foo
> $ cat b.c
> extern int foo;
> int main(void){ foo =3D 0; return 0;}
> $ gcc -c b.c && nm b.o
> 00000024 S ___i686.get_pc_thunk.cx
> =A0 =A0 =A0 =A0 =A0U _foo
> 00000000 T _main
>
> --
> FX

But that is a "decoration" that is not visible on the C side, is it?
Just like Fortran names often get an underscore appended or get
converted to uppercase. Those name manglings are visible to the linker
and the compiler, they have nothing to do with the source code an
ordinary programmer writes.

(Or maybe I have misinterpreted the question - that happens ;))

Regards,

Arjen

Craig Powers

2008-03-14, 7:32 pm

Arjen Markus wrote:
> On 14 mrt, 09:37, "FX" <coud...@alussinan.org> wrote:
>
> But that is a "decoration" that is not visible on the C side, is it?
> Just like Fortran names often get an underscore appended or get
> converted to uppercase. Those name manglings are visible to the linker
> and the compiler, they have nothing to do with the source code an
> ordinary programmer writes.
>
> (Or maybe I have misinterpreted the question - that happens ;))

We're talking about what appears in the object file, not what's visible
to either the Fortran side or the C side.

Arjen Markus

2008-03-14, 7:32 pm

On 14 mrt, 14:56, Craig Powers <eni...@hal-pc.org> wrote:

> We're talking about what appears in the object file, not what's visible
> to either the Fortran side or the C side.

Right, I missed that nuance ;).

(I have had to resort to inspecting these files too many times to not
appreciate the difference)

Regards,

Arjen

Steve Lionel

2008-03-14, 7:32 pm

On Mar 13, 1:40 pm, Henrik Holst <henrikhols...@gmail.com> wrote:

> MODULE GLOBALS
> IMPLICIT NONE
> INTEGER, BIND(C) :: FOO
> END GLOBALS
>
> G95 gave me no symbol named "foo" in the object file. Intel 10 and
> Sunstudio 12 gave me a symbol called "foo" (4 byte integer on my x86
> 32bit platform).
>
> How is this supposed to be interpreted? I have asked about this before
> in the G95 forums [1] and they said that G95:s interpretation was
> correct. But Intel usually is right in my experience so which one is
> it? Is the symbol "foo" supposed to be defined in "globals.o" or not?

The standard says (15.3):

A C variable with external linkage may interoperate with a common
block or with a variable declared
in the scope of a module. The common block or variable shall be
specified to have the BIND attribute.

It then proceeds to give the following partial example in a note:

-
The following are examples of the usage of the BIND attribute for
variables and for a common
block. The Fortran variables, C EXTERN and C2, interoperate with the C
variables, c extern and
myVariable, respectively. The Fortran common blocks, COM and SINGLE,
interoperate with the
C variables, com and single, respectively.

MODULE LINK_TO_C_VARS
USE, INTRINSIC :: ISO_C_BINDING
INTEGER(C_INT), BIND(C) :: C_EXTERN
INTEGER(C_LONG) :: C2
BIND(C, NAME='myVariable') :: C2
COMMON /COM/ R, S
REAL(C_FLOAT) :: R, S, T
BIND(C) :: /COM/, /SINGLE/
COMMON /SINGLE/ T
END MODULE LINK_TO_C_VARS
int c_extern;
long myVariable;
struct {float r, s;} com;
float single;
-

While I agree with those who say that the standard does not concern
itself with global symbols in object modules, I fail to understand how
a traditional compiled-code implementation can meet the standard of
interoperability with C global variables without an entry in the
global symbol table for the module variable.

I constructed the following complete test case - what does g95 do with
this?

C Code:

#include <stdio.h>
int c_extern;

void fsub(void);

void main (int argc, char *argv[])
{

c_extern = 123;
fsub();
printf(" Back from fsub, c_extern = %d\n",c_extern);
}

Fortran code:

module mymod
use, intrinsic :: iso_c_binding
integer(c_int), bind(C) :: c_extern
end module mymod

subroutine fsub () bind(C)
use mymod

print *, "In fsub, c_extern is ", c_extern

c_extern = 456

return
end subroutine fsub

Using Intel Visual Fortran and Microsoft Visual C++, I compile and
link these together. When I run it, I get:

In fsub, c_extern is 123
Back from fsub, c_extern = 456

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/pe...cetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran

Henrik Holst

2008-03-14, 7:32 pm

On Mar 14, 9:14=A0pm, Steve Lionel <steve.lio...@intel.com> wrote:
> On Mar 13, 1:40 pm, Henrik Holst <henrikhols...@gmail.com> wrote:
>
>
>
>
> The standard says (15.3):
>
> A C variable with external linkage may interoperate with a common
> block or with a variable declared
> in the scope of a module. The common block or variable shall be
> specified to have the BIND attribute.
>
> It then proceeds to give the following partial example in a note:
>
> -
> The following are examples of the usage of the BIND attribute for
> variables and for a common
> block. The Fortran variables, C EXTERN and C2, interoperate with the C
> variables, c extern and
> myVariable, respectively. The Fortran common blocks, COM and SINGLE,
> interoperate with the
> C variables, com and single, respectively.
>
> MODULE LINK_TO_C_VARS
> USE, INTRINSIC :: ISO_C_BINDING
> INTEGER(C_INT), BIND(C) :: C_EXTERN
> INTEGER(C_LONG) :: C2
> BIND(C, NAME=3D'myVariable') :: C2
> COMMON /COM/ R, S
> REAL(C_FLOAT) :: R, S, T
> BIND(C) :: /COM/, /SINGLE/
> COMMON /SINGLE/ T
> END MODULE LINK_TO_C_VARS
> int c_extern;
> long myVariable;
> struct {float r, s;} com;
> float single;
> -
>
> While I agree with those who say that the standard does not concern
> itself with global symbols in object modules, I fail to understand how
> a traditional compiled-code implementation can meet the standard of
> interoperability with C global variables without an entry in the
> global symbol table for the module variable.
>
> I constructed the following complete test case - what does g95 do with
> this?
>
> C Code:
>
> #include <stdio.h>
> int c_extern;
>
> void fsub(void);
>
> void main (int argc, char *argv[])
> {
>
> c_extern =3D 123;
> fsub();
> printf(" Back from fsub, c_extern =3D %d\n",c_extern);
>
> }
>
> Fortran code:
>
> module mymod
> use, intrinsic :: iso_c_binding
> integer(c_int), bind(C) :: c_extern
> end module mymod
>
> subroutine fsub () bind(C)
> use mymod
>
> print *, "In fsub, c_extern is ", c_extern
>
> c_extern =3D 456
>
> return
> end subroutine fsub
>
> Using Intel Visual Fortran and Microsoft Visual C++, I compile and
> link these together. When I run it, I get:
>
> =A0In fsub, c_extern is =A0 =A0 =A0 =A0 =A0123
> =A0Back from fsub, c_extern =3D 456
>
> --
> Steve Lionel
> Developer Products Division
> Intel Corporation
> Nashua, NH
>
> User communities for Intel Software Development Products
> =A0http://softwareforums.intel.com/
> Intel Fortran Support
> =A0http://support.intel.com/support/performancetools/fortran
> My Fortran blog
> =A0http://www.intel.com/software/drfortran

Hi Steve Lionel,

I get the same resusts in g95 (gcc version 4.0.3 (g95 0.91!) Nov 16
2007) as you do:

""
In fsub, c_extern is 123
Back from fsub, c_extern =3D 456
""

(For the C part I used: gcc version 4.1.3 20070929 (prerelease)
(Ubuntu 4.1.2-16ubuntu2))
--
Henrik Holst, Sweden
http://www.nada.kth.se/~holst/contact.shtml

Steve Lionel

2008-03-14, 10:36 pm

On Mar 14, 6:19 pm, Henrik Holst <henrikhols...@gmail.com> wrote:

> I get the same resusts in g95 (gcc version 4.0.3 (g95 0.91!) Nov 16
> 2007) as you do:

Ok, then perhaps you are mistaken about no symbols for the variables?
What does "nm -a" show for the module .o?

Steve

Craig Powers

2008-03-15, 10:37 pm

Steve Lionel wrote:
>
> While I agree with those who say that the standard does not concern
> itself with global symbols in object modules, I fail to understand how
> a traditional compiled-code implementation can meet the standard of
> interoperability with C global variables without an entry in the
> global symbol table for the module variable.

I certainly didn't intend to suggest otherwise. My point was only that
the symbol might not be named "foo" exactly, although it would almost
certainly contain "foo" as part of it.

Henrik Holst

2008-03-19, 4:32 am

On Mar 15, 2:22 am, Steve Lionel <steve.lio...@intel.com> wrote:
> On Mar 14, 6:19 pm, Henrik Holst <henrikhols...@gmail.com> wrote:
>
>
> Ok, then perhaps you are mistaken about no symbols for the variables?
> What does "nm -a" show for the module .o?
>
> Steve

Hmm, not much

$ nm -a mymod.o

mymod.o:
00000000 b .bss
00000000 n .comment
00000000 d .data
00000000 n .note.GNU-stack
00000000 t .text
00000000 a mymod.f90

--
Henrik Holst, Sweden
http://www.nada.kth.se/~holst/contact.shtml

Steve Lionel

2008-03-19, 7:15 pm

On Mar 18, 8:18 pm, Henrik Holst <henrikhols...@gmail.com> wrote:

[color=darkred]
> Hmm, not much
>
> $ nm -a mymod.o
>
> mymod.o:
> 00000000 b .bss
> 00000000 n .comment
> 00000000 d .data
> 00000000 n .note.GNU-stack
> 00000000 t .text
> 00000000 a mymod.f90

Interesting. Perhaps someone more familiar with G95 can comment -
maybe there's another mechanism at work.

Steve

Sponsored Links