gfortran iso c bindings - capabilities
Brendan
using the iso c bindings. These bindings are fairly new and there are
not many examples on the internet, though I have heard "fortran
95/2003 explained" has a whole chapter dedicated to this topic.
Is it possible to call any c function from gfortran? The api has many
structure data types.
Arjen Markus
You may be interested in my C wrapper then - at http://flibs.sf.net.
It is not finished yet, but it should
get a lot of the tedious stuff out of the way (it may break
on some complicated C preprocessing features though).
To return to your question:
With the ISO_C_BINDING features interfacing to C because
a lot easier (especially much less platform-dependent).
You can transfer data in structures (derived types or C structs),
but there are some intrinsic limitations - C pointers versus
Fortran pointers for instance. Not to mention Fortran
allocatables.
The last couple of weeks there were several threads related
to the subject. They provide interesting reading - especially
the article by John Reid (referenced in one of them).
Regards,
Arjen
Brendan
> On 12 mrt, 15:10, Brendan <brendandetra...@yahoo.com> wrote:
>
> > I have a large api written in c which I want call from gfortran(4.3.0)
> > using the iso c bindings. These bindings are fairly new and there are
> > not many examples on the internet, though I have heard "fortran
> > 95/2003 explained" has a whole chapter dedicated to this topic.
>
> > Is it possible to call any c function from gfortran? The api has many
> > structure data types.
>
> It is not finished yet, but it should
> get a lot of the tedious stuff out of the way (it may break
> on some complicated C preprocessing features though).
>
> To return to your question:
> With the ISO_C_BINDING features interfacing to C because
> a lot easier (especially much less platform-dependent).
> You can transfer data in structures (derived types or C structs),
> but there are some intrinsic limitations - C pointers versus
> Fortran pointers for instance. Not to mention Fortran
> allocatables.
>
> The last couple of weeks there were several threads related
> to the subject. They provide interesting reading - especially
> the article by John Reid (referenced in one of them).
>
> Regards,
>
> Arjen
Yes, I have the John Reid text. It is the only "published" text with
examples. I need the examples because I am not up to speed on fortran
90/95/2003 and do not know c. Sure I can read the relevant section of
Intel's fortran manual, but there are _no_ examples.
Most people are more interested in calling fortran from c.
Arjen Markus
>
> - Tekst uit oorspronkelijk bericht weergeven -
"Fortran 95/2003 explained" has a number of examples too,
though I agree we could do with more publications.
(I am, by the way, also working on a wrapper to make calling
Fortran from C a bit easier)
Regards,
Arjen
James Van Buskirk
news:e036a926-344e-4117...@p25g2000hsf.googlegroups.com...
I have examples:
http://home.comcast.net/~kmbtib/Fortran_stuff/hello1.f90
http://home.comcast.net/~kmbtib/Fortran_stuff/HelloWin1.f90
They only work in the 64-bit versions of gfortran because there
are problems with the STDCALL calling convention that gcc hasn't
worked out yet. Looking at bugzilla and the gfortran mailing
list there seems to be some progress in that area (perhaps a
wrongheaded approach, but still progress)
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
FX
> problems with the STDCALL calling convention that gcc hasn't worked out
> yet.
You'll certainly be glad to hear that I'm working on that, and this will
most probably be fixed in the 4.4 development branch.
> Looking at bugzilla and the gfortran mailing list there seems to be
> some progress in that area (perhaps a wrongheaded approach, but still
> progress)
Hum? I've looked up "wrongheaded" in my dictionary, and it doesn't quite
seem like a compliment. Can you formulate constructive criticism of the
approach currently taken?
--
FX
FX
> problems with the STDCALL calling convention that gcc hasn't worked out
> yet.
You'll certainly be glad to hear that I'm working on that, and this will
most probably be fixed in the 4.4 development branch.
> Looking at bugzilla and the gfortran mailing list there seems to be
> some progress in that area (perhaps a wrongheaded approach, but still
> progress)
Hum? I've looked up "wrongheaded" in my dictionary, and it doesn't quite
seem like a compliment. Would you mind elaborating on what you don't like
in the approach currently taken?
--
FX
Jugoslav Dujic
Not being a native speaker (either?) I parsed James's "wrongheaded" as
"headed into a wrong direction", and I'm fairly sure that was intended meaning.
Not that I wasn't surprised too by what dictionary said...
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
Brendan
> I have examples:http://home.comcast.net/~kmbtib/Fortran_stuff/hello1.f90http://home.comcast.net/~kmbtib/Fortran_stuff/HelloWin1.f90
> They only work in the 64-bit versions of gfortran because there
> are problems with the STDCALL calling convention that gcc hasn't
> worked out yet.
Thanks for the examples. Thankfully I am working with Linux and won't
have to worry about Windows eccentricities. I am sure I'll be posting
another question soon.
Tim Prince
> FX wrote:
> || They only work in the 64-bit versions of gfortran because there are
> || problems with the STDCALL calling convention that gcc hasn't worked out
> || yet.
> |
> | You'll certainly be glad to hear that I'm working on that, and this will
> | most probably be fixed in the 4.4 development branch.
> |
> || Looking at bugzilla and the gfortran mailing list there seems to be
> || some progress in that area (perhaps a wrongheaded approach, but still
> || progress)
> |
> | Hum? I've looked up "wrongheaded" in my dictionary, and it doesn't quite
> | seem like a compliment. Can you formulate constructive criticism of the
> | approach currently taken?
>
> Not being a native speaker (either?) I parsed James's "wrongheaded" as
> "headed into a wrong direction", and I'm fairly sure that was intended meaning.
> Not that I wasn't surprised too by what dictionary said...
>
well as being less important in view of ISO C binding, "wrongheaded" may
fit, but I don't know if that was the reason for introduction of that
appelation.
James Van Buskirk
news:fr8vba$r4i$2...@nef.ens.fr...
"wrongheaded" was shorthand for a more detailed technical comment.
My impression (from PR 34112 or so) was that your intent was to
implement the !DEC$ ATTRIBUTES extensions to create capability
for gfortran to interoperate in a 32-bit Windows environment.
In previous messages in this forum I have pointed out that
gfortran could achieve this goal without defining any new syntax,
just by implementing or extending the syntax available already.
At this point in time it seems to me more instructive to attempt
to get everything necessary done using the standard bind(C)
features, and if it really is determined that there is stuff that
is desirable but simply can't be attained by this path, then it
would be a good thing to find out before f08 comes out. ifort
is a good compiler and all that, but it doesn't seem to me to be
desirable to be bug-compatible with it -- and it has bugs that
Intel will not or cannot fix.
I recall Steve Lionel mentioned that bind(C) and STDCALL are
considered incompatible in the ifort design document. Maybe
this is just a dilatory tactic to see what mistakes others make
in this area before committing themselves to any syntax rules
they might regret later, but for now the combination of bind(C)
and STDCALL is unique to gfortran, hence a weirdness of the
compiler.
BTW, what other compilers have an implementation of Directive
Enhanced Compilation? I have heard it referred to as an industry
standard somewhere, but who in the industry is following the
standard, and in what way is their usage different from Intel?
You focused on the "wrongheaded" bit but not on the "progress"
part. Progress in the sense that no matter what you do you are
going to have to include the calling convention as part of the
data structure that describes a procedure's interface. Not to
mention that the compiler will have to know how to mangle all
names so that it would be simple after that to make the
existing compiler switch that forces name mangling to function
in all cases, not just a frustrating few. I don't know what
dllimport and dllexport are supposed to do for gfortran since
it's already possible to write DLLs and link to them with that
toolset. I suppose fastcall refers to the GNU fastcall, rather
than different conventions with the same name by Microsoft or
even Borland?
Well, my opinion is that it doesn't look like gfortran is all
that far from being able to interoperate with Win32 API
functions, even in 32-bit Windows. I worry that big chunks of
cruft may unnecessarily be added to the compiler in the
process which will require some kind of maintainence long after
32-bit Windows loses its popularity as a Fortran venue.
jwm
> "FX" <coud...@alussinan.org> wrote in message
>
> news:fr8vba$r4i$2...@nef.ens.fr...
>
> BTW, what other compilers have an implementation of Directive
> Enhanced Compilation? I have heard it referred to as an industry
> standard somewhere, but who in the industry is following the
> standard, and in what way is their usage different from Intel?
I know Absoft and IBM accept compiler directives (the trigger for
Absoft's compiler is "!DIR$" and for IBM's compiler is "!IBM*"). I
certainly prefer to use those directives instead of fpp, and I really
wonder why the Fortran Standard decided to propose CoCo instead of
just standardizing the existing practice ---my experience with CoCo
reduced to downloading the source, compiling, reading the manual, and
finally forgetting about it.
By the way, the term "Directive Enhanced Compilation" is just
something Intel made up to avoid the reference to Digital Equipment
Corporation; IBM refers to them as Comment Form Directives (to
distinguish them from INCLUDE).
John.
FX
> implement the !DEC$ ATTRIBUTES extensions to create capability for
> gfortran to interoperate in a 32-bit Windows environment.
The plan currently is to implement a sed of "!GNU$ ATTRIBUTES" that would
correspond (or at least be similar) to the attributes available in the C
language family in GCC (in C, the syntax is "__attribute__ ((...))").
The reasons for not implementing straight away the DEC attributes are:
-- they are incompatible with C interoperability (or, at least, the way
they work together is unclear)
-- their semantics vary across platforms
-- some of them are strongly tied to Win32 calling conventions which,
at some point, will disappear; we thus need, in the long term, a
more generic solution without possible conflicts
-- DEC attributes are tied to the Intel development team, so we
couldn't extend them at will (for example, GCC has attributes to
indicate that a given function is "hot" or "cold", or to influence
inlining, that might be usefull to use from Fortran)
So, all in all, it seems to be better to implement our own extended
attributes. Easier on the user, even if it means porting existing code
(and good code factoring, advised as usual, makes that a light
requirement).
> In previous messages in this forum I have pointed out that gfortran
> could achieve this goal without defining any new syntax, just by
> implementing or extending the syntax available already.
We have considered extending the bind(c) syntax to things like:
bind(c,name="foo",attributes="decorate,stdcall")
but it would be a very invasive extension, while the "!GNU$ ATTRIBUTES"
syntax is seen as a comment on other compilers, and thus compiles fine.
(OpenMP support and other vendors have shown that it's a very reasonable
way to devise extensions, in my opinion.)
> At this point in time it seems to me more instructive to attempt to get
> everything necessary done using the standard bind(C) features
Well, the bind(C) standard features aren't designed to mess with
different calling conventions. It's a bit sad, knowing the real-life
situation, but that's how it is.
> and if it really is determined that there is stuff that is desirable
> but simply can't be attained by this path, then it would be a good
> thing to find out before f08 comes out.
What are you suggesting?
> I don't know what dllimport and dllexport are supposed to do
The documentation for them is here:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
I've never used them, but the mingw maintainer of GCC suggested they be
included, IIRC.
> I suppose fastcall refers to the GNU fastcall, rather than different
> conventions with the same name by Microsoft or even Borland?
Yes. Documentation available on the same web page.
> Well, my opinion is that it doesn't look like gfortran is all that far
> from being able to interoperate with Win32 API functions, even in
> 32-bit Windows.
Well, I certainly feel it can make it into 4.4. What will be needed are
examples and testing, but I'm sure knowing your willingness to expose
flaws in compilers, you'll be happy to lend a hand! :)
> I worry that big chunks of cruft may unnecessarily be added to the
> compiler in the process which will require some kind of maintainence
> long after 32-bit Windows loses its popularity as a Fortran venue.
That's the nice thing (IMHO) about having a GNU attributes extension: I'm
sure having a generic framework for setting middle-end attributes will be
useful for other purposes: you can set alignment and packing of types and
variables, create constructors and destructors, define symbols as weak,
etc.
--
FX
FX
> implement the !DEC$ ATTRIBUTES extensions to create capability for
> gfortran to interoperate in a 32-bit Windows environment.
The plan currently is to implement a sed of "!GNU$ ATTRIBUTES" that would
correspond (or at least be similar) to the attributes available in the C
language family in GCC (in C, the syntax is "__attribute__ ((...))").
The reasons for not implementing straight away the DEC attributes are:
-- they are incompatible with C interoperability (or, at least, the way
they work together is unclear)
-- their semantics vary across platforms
-- some of them are strongly tied to Win32 calling conventions which,
at some point, will disappear; we thus need, in the long term, a
more generic solution without possible conflicts
-- DEC attributes are tied to the Intel development team, so we
couldn't extend them at will (for example, GCC has attributes to
indicate that a given function is "hot" or "cold", or to influence
inlining, that might be usefull to use from Fortran)
So, all in all, it seems to be better to implement our own extended
attributes. Easier on the user, even if it means porting existing code
(and good code factoring, advised as usual, makes that a light
requirement).
> In previous messages in this forum I have pointed out that gfortran
> could achieve this goal without defining any new syntax, just by
> implementing or extending the syntax available already.
We have considered extending the bind(c) syntax to things like:
bind(c,name="foo",attributes="decorate,stdcall")
but it would be a very invasive extension, while the "!GNU$ ATTRIBUTES"
syntax is seen as a comment on other compilers, and thus compiles fine.
(OpenMP support and other vendors have shown that it's a very reasonable
way to devise extensions, in my opinion.)
> At this point in time it seems to me more instructive to attempt to get
> everything necessary done using the standard bind(C) features
Well, the bind(C) standard features aren't designed to mess with
different calling conventions. It's a bit sad, knowing the real-life
situation, but that's how it is.
> and if it really is determined that there is stuff that is desirable
> but simply can't be attained by this path, then it would be a good
> thing to find out before f08 comes out.
What are you suggesting?
> I don't know what dllimport and dllexport are supposed to do
The documentation for them is here:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
I've never used them, but the mingw maintainer of GCC suggested they be
included, IIRC.
> I suppose fastcall refers to the GNU fastcall, rather than different
> conventions with the same name by Microsoft or even Borland?
Yes. Documentation available on the same web page.
> Well, my opinion is that it doesn't look like gfortran is all that far
> from being able to interoperate with Win32 API functions, even in
> 32-bit Windows.
Well, I certainly feel it can make it into 4.4. What will be needed are
examples and testing, but I'm sure knowing your willingness to expose
flaws in compilers, you'll be happy to lend a hand! :)
> I worry that big chunks of cruft may unnecessarily be added to the
> compiler in the process which will require some kind of maintainence
> long after 32-bit Windows loses its popularity as a Fortran venue.
That's the nice thing (IMHO) about having a GNU attributes extension: I'm
sure having a generic framework for setting middle-end attributes will be
useful for other purposes: you can set alignment and packing of types and
variables, create constructors and destructors, define symbols as weak,
etc.
All comments are very welcome, both here and on the for...@gcc.gnu.org
mailing-list if you feel like this is off-topic here. The more input we
get, the fewer chances you will find reasons to complain in the future :)
--
FX
Gary Scott
>>My impression (from PR 34112 or so) was that your intent was to
>>implement the !DEC$ ATTRIBUTES extensions to create capability for
>>gfortran to interoperate in a 32-bit Windows environment.
>
>
> The plan currently is to implement a sed of "!GNU$ ATTRIBUTES" that would
> correspond (or at least be similar) to the attributes available in the C
> language family in GCC (in C, the syntax is "__attribute__ ((...))").
>
> The reasons for not implementing straight away the DEC attributes are:
> -- they are incompatible with C interoperability (or, at least, the way
> they work together is unclear)
> -- their semantics vary across platforms
> -- some of them are strongly tied to Win32 calling conventions which,
> at some point, will disappear; we thus need, in the long term, a
> more generic solution without possible conflicts
You should not assume that the need to support alternate calling
conventions will go away in the near term. Lots of applications are
being written that assume 32 bit operating systems will be around for a
considerable length of time (decades at least). In addition, it is
valuable to have those features to interoperate with languages besides
C. The feature set provided by the MS F/MS FPS/DVF/CVF/IVF line are so
extensive as to handle almost any conceivable (likely) calling
convention. I would hope that you minimally include all of the same
capabilities provided by the !DEC$ directives. I also use those
features in order to cause the compiler to generate static libraries or
DLLs that are compatible with other compilers that default to STDCALL
calling mechanism. With IVF, I have been able to create libraries
compatible with several (ok 3) of the current Windows compilers,
regardless of their chosen default convention. I would like to be able
to target other compilers in this way.
> -- DEC attributes are tied to the Intel development team, so we
> couldn't extend them at will (for example, GCC has attributes to
> indicate that a given function is "hot" or "cold", or to influence
> inlining, that might be usefull to use from Fortran)
>
> So, all in all, it seems to be better to implement our own extended
> attributes. Easier on the user, even if it means porting existing code
> (and good code factoring, advised as usual, makes that a light
> requirement).
>
While, I would prefer that we evolve toward the DEC syntax, I'm more
concerned with providing all of the required functionality. Just
because the Windows OS on 64-bit now defaults to MS' version of a C
calling convention, doesn't mean I want to be so restricted.
>
>>In previous messages in this forum I have pointed out that gfortran
>>could achieve this goal without defining any new syntax, just by
>>implementing or extending the syntax available already.
>
>
> We have considered extending the bind(c) syntax to things like:
> bind(c,name="foo",attributes="decorate,stdcall")
> but it would be a very invasive extension, while the "!GNU$ ATTRIBUTES"
> syntax is seen as a comment on other compilers, and thus compiles fine.
> (OpenMP support and other vendors have shown that it's a very reasonable
> way to devise extensions, in my opinion.)
I oppose these types of extensions in general, unless, minimally, they
are clearly identifiable as extensions, for example rather than a
generic keyword (that might later conflict with a standard keyword),
GCC_attributes="..." (or something) would be somewhat better.
>
>
>>At this point in time it seems to me more instructive to attempt to get
>>everything necessary done using the standard bind(C) features
>
>
> Well, the bind(C) standard features aren't designed to mess with
> different calling conventions. It's a bit sad, knowing the real-life
> situation, but that's how it is.
Very disappointing...BIND(C) isn't nearly so useful if you still have to
pepper it with directives.
<snip>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
James Van Buskirk
>> At this point in time it seems to me more instructive to attempt to get
>> everything necessary done using the standard bind(C) features
> Well, the bind(C) standard features aren't designed to mess with
> different calling conventions. It's a bit sad, knowing the real-life
> situation, but that's how it is.
Uh, yeah, but pre-existing gfortran compilation switches are so
designed. This was discussed in the thread
http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/19d77dfc75f8be58
and discussed in more detail in the message
http://groups.google.com/group/comp.lang.fortran/msg/e2f9423c0473036a
The general idea is that the -mrtd switch can be used to force
functions and interfaces compiled to use STDCALL calling convention
and that the switch --enable-stdcall-fixup could enable and
--disable-stdcall-fixup could disable name decoration. I don't
know why --enable-stdcall-fixup works for some procedures but
not for most. The documentation on that switch IIRC is rather
sparse.
>> and if it really is determined that there is stuff that is desirable
>> but simply can't be attained by this path, then it would be a good
>> thing to find out before f08 comes out.
> What are you suggesting?
It's not like I have found anything up to this point that requires
fixing in the standard in this regard, but that implementation of
the possibilities available in f03 might well reveal some problems
that in would be nice to get fixed by the f08 stage of development.
>> I don't know what dllimport and dllexport are supposed to do
> The documentation for them is here:
> http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
> I've never used them, but the mingw maintainer of GCC suggested they be
> included, IIRC.
That document says that dllexport is unnecessary on Windows because
you could export everything via the --export-all switch (to ld.exe I
presume) or if fine control is needed, a *.def file as has been
demonstrated in this forum (sample message
http://groups.google.com/group/comp.lang.fortran/msg/f3f0d21bb508812f )
Also it says that dllimport is not necessary in Windows. There is also
LoadLibrary/GetProcAddress
http://groups.google.com/group/comp.lang.fortran/msg/b5065aaaad9eb748
although that example is quite old and I may do things differently
since then.
>> Well, my opinion is that it doesn't look like gfortran is all that far
>> from being able to interoperate with Win32 API functions, even in
>> 32-bit Windows.
> Well, I certainly feel it can make it into 4.4. What will be needed are
> examples and testing, but I'm sure knowing your willingness to expose
> flaws in compilers, you'll be happy to lend a hand! :)
My opinion is that you are closer than you think.
> That's the nice thing (IMHO) about having a GNU attributes extension: I'm
> sure having a generic framework for setting middle-end attributes will be
> useful for other purposes: you can set alignment and packing of types and
> variables, create constructors and destructors, define symbols as weak,
> etc.
ifort uses padding for alignment unless SEQUENCE is in force, but
I guess that is inconsistent with bind(C) due to C1501. Maybe
packed types have to be approached like UNIONs at the present state
of the standard, which means maintaining them by hand.
Dick Hendrickson
free to pick any companion processor it chooses. In particular, I
think it can make a command line driven decision to pick the companion
that uses whatever calling conventions the user wants. I think that was
the intent of the interoperability feature. A Fortran processor is
likely to have several available companions and the user picks one at
compile time. The various companions could be the same C compiler
invoked with different command line options.
Bind(C) won't work well if more than one calling sequence is needed
for the same Fortran program.
Dick Hendrickson
James Van Buskirk
news:sa%Cj.13674$D_3....@bgtnsc05-news.ops.worldnet.att.net...
> I haven't been following this thread in detail. But, the processor is
> free to pick any companion processor it chooses. In particular, I
> think it can make a command line driven decision to pick the companion
> that uses whatever calling conventions the user wants. I think that was
> the intent of the interoperability feature. A Fortran processor is
> likely to have several available companions and the user picks one at
> compile time. The various companions could be the same C compiler
> invoked with different command line options.
That is just what I am trying to do -- use command-line switches to
determine whether the calling convention is _cdecl or _stdcall.
> Bind(C) won't work well if more than one calling sequence is needed
> for the same Fortran program.
That may be, but I am hoping to at least be able to limp along.
The current example is:
http://home.comcast.net/~kmbtib/Fortran_stuff/multi_test.ZIP
Here's how it works on xp-x64:
C:\gfortran\test\multi_test>gfortran -v
Built by Equation Solution (http://www.Equation.com).
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../gcc-4.4-20080307-mingw/configure --host=x86_64-pc-mingw32 --
build=x86_64-unknown-linux-gnu --target=x86_64-pc-mingw32 --prefix=/home/gfortra
n/gcc-home/binary/mingw32/native/x86_64/gcc/4.4-20080307 --with-gmp=/home/gfortr
an/gcc-home/binary/mingw32/native/x86_64/gmp --with-mpfr=/home/gfortran/gcc-home
/binary/mingw32/native/x86_64/mpfr --with-sysroot=/home/gfortran/gcc-home/binary
/mingw32/cross/x86_64/gcc/4.4-20080307 --with-gcc --with-gnu-ld --with-gnu-as
--
disable-shared --disable-nls --disable-tls --enable-languages=c,fortran --enable
-libgomp --enable-threads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.4.0 20080307 (experimental) (GCC)
C:\gfortran\test\multi_test>type make_multi_test.bat
@echo off
set gfc=C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
rem set gfc=C:\gfortran\bin\gfortran
%gfc% -c user32_cdecl.f90
if %errorlevel% NEQ 0 goto errorexit
%gfc% -mrtd -enable-stdcall-fixup -c user32_stdcall.f90
if %errorlevel% NEQ 0 goto errorexit
%gfc% -c user32.f90
if %errorlevel% NEQ 0 goto errorexit
%gfc% -mrtd -enable-stdcall-fixup -c kernel32.f90
if %errorlevel% NEQ 0 goto errorexit
%gfc% multi_test.f90 -lkernel32 -luser32 -omulti_test
if %errorlevel% NEQ 0 goto errorexit
goto goodexit
:errorexit
echo Sorry, error detected
:goodexit
C:\gfortran\test\multi_test>make_multi_test
f951.exe: warning: -mrtd is ignored in 64bit mode
f951.exe: warning: -mrtd is ignored in 64bit mode
C:\gfortran\test\multi_test>multi_test
Address of GetStdHandle = 0000000000401740
As you can see, this version of make_multi_test.bat uses the version
of gfortran that makes 64-bit executables. The one in the *.ZIP
archive is geared towards 32-bit output. The program will need
Win32 APIs, some of which are STDCALL, but one of which is not.
The files containing the interface blocks, user32_cdecl.f90 and
kernel32.f90, are compiled with different command-line switches.
The compiler is supposed to incorporate the information about the
calling convention in the data strutures describing the explicit
interfaces in user32_cdecl.mod and kernel32.mod, which should
eventually get passed along to the compiler when it compiles
multi_test.f90 so that all procedures will be invoked correctly.
This works fine in the x64 world because there is only one calling
convention there and there is no need to create another one because
that ISA isn't as short on registers as in *32-land. This isn't
really getting tested on 32-bit windows:
C:\gfortran\test\multi_test>gfortran -v
Using built-in specs.
Target: i586-pc-mingw32
Configured with:
../trunk/configure --prefix=/mingw --enable-languages=c,fortran
--with-gmp=/home/FX/local --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --dis
able-werror --enable-bootstrap --enable-threads --disable-nls --build=i586-pc-mi
ngw32 --enable-libgomp --disable-shared
Thread model: win32
gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] (GCC)
C:\gfortran\test\multi_test>make_multi_test
C:\DOCUME~1\James\LOCALS~1\Temp/ccfZDSSl.o:multi_test.f90:(.text+0x2b):
undefine
d reference to `GetStdHandle'
C:\DOCUME~1\James\LOCALS~1\Temp/ccfZDSSl.o:multi_test.f90:(.text+0xab):
undefine
d reference to `GetStdHandle'
C:\DOCUME~1\James\LOCALS~1\Temp/ccfZDSSl.o:multi_test.f90:(.text+0x15a):
undefin
ed reference to `WriteFile'
collect2: ld returned 1 exit status
Sorry, error detected
The -enable-stdcall-fixup switch doesn't work except for a very few
functions, so gfortran isn't making the right names to link with
libkernel32.a and libuser32.a. Now, if this switch magically worked,
it would be possible to determine whether my approach is going to
work in gfortran, but for now it's a big question mark.
James Van Buskirk
news:CIedndbWS8edB0Da...@comcast.com...
> Here's how it works on xp-x64:
> C:\gfortran\test\multi_test>gfortran -v
> Built by Equation Solution (http://www.Equation.com).
Actually, this isn't the version of gfortran I used in this test.
I used the x86_64 version from FX's website.
FX
> functions, so gfortran isn't making the right names to link with
> libkernel32.a and libuser32.a. Now, if this switch magically worked,
> it would be possible to determine whether my approach is going to work
> in gfortran, but for now it's a big question mark.
To prove your approach, have you thought of compiling all to assembly,
hand-modifying the assembler names of the functions called, and the
assemble and link?
--
FX
James Van Buskirk
I guess I'm sort of asking you to do something horrible for me, so
it's only fair that the nature of the task is reflected on me:
C:\gfortran\test\MULTI_~1>gfortran -v
Using built-in specs.
Target: i586-pc-mingw32
Configured with:
../trunk/configure --prefix=/mingw --enable-languages=c,fortran
--with-gmp=/home/FX/local --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --dis
able-werror --enable-bootstrap --enable-threads --disable-nls --build=i586-pc-mi
ngw32 --enable-libgomp --disable-shared
Thread model: win32
gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] (GCC)
C:\gfortran\test\multi_test>gfortran -S multi_test.f90
multi_test.s is edited to:
.file "multi_test.f90"
.section .rdata,"dr"
.align 4
_options.0.575:
.long 68
.long 255
.long 0
.long 0
.long 0
.long 1
.long 0
LC0:
.ascii "%s%p\12\0"
LC1:
.ascii "Address of GetStdHandle = \0"
LC2:
.ascii "\0"
.text
.globl _MAIN__
.def _MAIN__; .scl 2; .type 32; .endef
_MAIN__:
pushl %ebp
movl %esp, %ebp
subl $312, %esp
movl $_options.0.575, 4(%esp)
movl $7, (%esp)
call __gfortran_set_options
movl $-11, -12(%ebp)
movl -12(%ebp), %eax
movl %eax, (%esp)
call _GetStdHandle@4
movl %eax, -24(%ebp)
movl $6, 8(%esp)
movl $LC0, 4(%esp)
leal -276(%ebp), %eax
movl %eax, (%esp)
call _memmove
movl $74, 8(%esp)
movl $32, 4(%esp)
leal -276(%ebp), %eax
addl $6, %eax
movl %eax, (%esp)
call _memset
movl $27, 8(%esp)
movl $LC1, 4(%esp)
leal -116(%ebp), %eax
movl %eax, (%esp)
call _memmove
movl $53, 8(%esp)
movl $32, 4(%esp)
leal -116(%ebp), %eax
addl $27, %eax
movl %eax, (%esp)
call _memset
movl $_GetStdHandle@4, %eax
movl %eax, -28(%ebp)
movl $4, 8(%esp)
leal -28(%ebp), %eax
movl %eax, 4(%esp)
leal -36(%ebp), %eax
movl %eax, (%esp)
call _memcpy
movl -36(%ebp), %eax
movl %eax, -8(%ebp)
movl -8(%ebp), %eax
movl %eax, 12(%esp)
leal -116(%ebp), %eax
movl %eax, 8(%esp)
leal -276(%ebp), %eax
movl %eax, 4(%esp)
leal -196(%ebp), %eax
movl %eax, (%esp)
call _wsprintfA
movl %eax, -4(%ebp)
movl $0, 16(%esp)
movl $LC2, 12(%esp)
movl $1, 8(%esp)
leal -196(%ebp), %eax
movl %eax, 4(%esp)
movl $80, (%esp)
call __gfortran_string_index
decl %eax
movl %eax, -16(%ebp)
movl $0, -20(%ebp)
movl -20(%ebp), %eax
movl %eax, 16(%esp)
leal -32(%ebp), %eax
movl %eax, 12(%esp)
movl -16(%ebp), %eax
movl %eax, 8(%esp)
leal -196(%ebp), %eax
movl %eax, 4(%esp)
movl -24(%ebp), %eax
movl %eax, (%esp)
call _WriteFile@20
movl %eax, -4(%ebp)
leave
ret
.def __gfortran_set_options; .scl 2; .type 32; .endef
.def _memmove; .scl 2; .type 32; .endef
.def _memset; .scl 2; .type 32; .endef
.def _GetStdHandle@4; .scl 2; .type 32; .endef
.def _memcpy; .scl 2; .type 32; .endef
.def _wsprintfA; .scl 2; .type 32; .endef
.def __gfortran_string_index; .scl 2; .type 32; .endef
.def _WriteFile@20; .scl 2; .type 32; .endef
with result:
C:\gfortran\test\MULTI_~1>gfortran
multi_test.s -lkernel32 -luser32 -omulti_test
C:\gfortran\test\MULTI_~1>multi_test
Address of GetStdHandle = 004014F0
The test was not unsuccessful! If -enable-stdcall-fixup worked,
we might just be smokin'!
FX
> we might just be smokin'!
If I understand well, you expect the following:
gfortran multi_test.f90 -lkernel32 -luser32 -mrtd -Wl,--enable-stdcall-fixup
to produce an executable that links fine and work as above, is that
right? I'm trying to get a small, reproducible testcase to work from.
--
FX
James Van Buskirk
Actually, the command line is given in make_multi_test.bat:
gfortran multi_test.f90 -lkernel32 -luser32 -omulti_test
The program itself is compiled without the switches. It's
supposed to know the calling conventions and mangled names from
the data at acquires via the MODULEs it USEs. It may be getting
the calling conventions or just be getting lucky in this regard,
but it doesn't seem to be getting the news about the name-mangling
at all.
FX
> this regard, but it doesn't seem to be getting the news about the
> name-mangling at all.
I'd say it's getting lucky. -mrtd is, as all GCC options starting with
-m, a target-specific option. That means, it is given its chance to shine
only when the code is generated, i.e. a long time after the Fortran
front-end has written its module files. This is, unfortunately as it may
be in this case, a choice of design; there is no way a -m option can
influence module files.
--
FX
James Van Buskirk
> I'm trying to get a small, reproducible testcase to work from.
It just occurred to me that I may have been too focused on today's
example to have gotten the meaning of your post. The multi_test stuff
is almost a complete test of everything needed for Win32 API
interoperability. If you were instead asking for only a test of whether
-enable-stdcall-fixup is working, a small example can be found at:
http://home.comcast.net/~kmbtib/Fortran_stuff/hello1.f90
The intent is that it should compile with:
gfortran -mrtd -enable-stdcall-fixup hello1.f90 -lkernel32 -ohello1
When -enable-stdcall-fixup works, it doesn't need the "-Wl," prefix,
at least with g95. Here's how it works in 64-bit gfortran:
C:\gfortran\clf\hello>gfortran -mrtd -enable-stdcall-fixup
hello1.f90 -lkernel32
-ohello1
f951.exe: warning: -mrtd is ignored in 64bit mode
C:\gfortran\clf\hello>hello1
Hello, world!
James Van Buskirk
Oog, that's bad news. Look at it this way: suppose you have a module:
module mod1
contains
function f(x)
f = 2*x+1
end function f
end module mod1
Now you compile the file containing the module with -mrtd:
gfortran -mrtd -c mod1.f90
So we USE that module in our program:
program main
USE mod1
write(*,*) f(1.0)
end program main
And we compile the file containing our program normally:
gfortran main.f90 mod1.o -omain
If mod1.mod doesn't have the information about what calling
convention to use, obviously main.exe is in danger of something bad
happening when it runs. The point I am trying to make is that if
you want
!DEC$ ATTRIBUTES STDCALL :: f
to work for the function f defined in module mod1, the compiler has
to be able to pass the information about the calling convention to
use via main.mod. So the information must be generated at the time
the front-end writes the module files. I was only anticipating
that achieving the same end via command-line switches would be
consistent with the behavior you seem to intend for Directive
Enhanced Compilation.
glen herrmannsfeldt
(snip)
> If mod1.mod doesn't have the information about what calling
> convention to use, obviously main.exe is in danger of something bad
> happening when it runs. The point I am trying to make is that if
> you want
> !DEC$ ATTRIBUTES STDCALL :: f
> to work for the function f defined in module mod1, the compiler has
> to be able to pass the information about the calling convention to
> use via main.mod.
Wouldn't it also work to require the same !DEC$ line in both
the module and the program using that module? Maybe a little
inconvenient, I suppose. I would expect all uses of
multiple incompatible calling conventions in the same
program to cause some inconvenience.
-- glen
FX
> -enable-stdcall-fixup is working
Yes, that's what I meant. I tried to get it working with a simple C
example, but I can't:
$ cat a.c
#include <stdio.h>
#include <stdint.h>
extern intptr_t GetStdHandle(long);
int main(void)
{
printf ("%ld\n", (long) GetStdHandle(-11));
return 0;
}
$ gcc a.c -lkernel32 -mrtd -Wl,--enable-stdcall-fixup
C:/DOCUME~1/FX/LOCALS~1/Temp/cc8Aaaaa.o:a.c:(.text+0x32): undefined reference to `GetStdHandle'
collect2: ld returned 1 exit status
$ gcc a.c -lkernel32 -mrtd -enable-stdcall-fixup
C:/DOCUME~1/FX/LOCALS~1/Temp/ccaMbaaa.o:a.c:(.text+0x32): undefined reference to `GetStdHandle'
collect2: ld returned 1 exit status
I looked at the assembly code and -mrtd indeed changes the calling
convention, but that's all. I suppose there is more to it than I thought.
Given that the issue is not Fortran-specific, this issue should be
brought to the mingw development list, I think.
--
FX