Hi guys....I've spent the whole night trying to figure out about this question. Please help me if you have any clue. Thanks a lot.
The code is very easy. I'm trying to call a fortran function from C.
The code is as follow:
=========C code========= #include "stdio.h"
extern float r_ (int * d, float *b);
main () { float a = 1.5, b = 1.05, c = 1; int d = 2; c = r_ (&d, &b); printf ("%f\n", c);
}
==========Fortran Code=========== real function r(m,t) integer m real t
print *, m, t r = 0.1*t+46 print *, r
return end ================================
It doesn't matter what the fortran code does...but when I compile it with g77, the result can't be passed back to the C code, but with gfortran, it can. Here are the outputs:
[du@brutus qr]$ ./testint.x 2 1.050000 46.10500 <----------- result in Fortran function 46.105000 <--------- result received by C code
***fortran code compiled by g77**** [du@brutus qr]$ g77 -funroll-all-loops -O3 -c ceiling.f -o ceiling.o;gcc -funroll-all-loops -O3 -c testint.c -o testint.o;g77 -o testint.x testint.o ceiling.o -L/pkgs/intel/mkl/9.0/lib/em64t -L/home/ du/lib/hpl/lib/LINUX_XEON_QUAD -L/usr/lib/gcc/x86_64-redhat-linux/ 3.4.6/ -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1 -L. -lgfortran [du@brutus qr]$ ./testint.x 2 1.04999995 46.1049995 -0.000000 <----------- but here I get 0, with the only difference in the way the fortran code is compiled.
Here are the versions: [du@brutus qr]$ g77 -v Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man -- infodir=/usr/share/info --enable-shared --enable-threads=posix -- disable-checking --with-system-zlib --enable-__cxa_atexit --disable- libunwind-exceptions --enable-languages=c,c++,f77 --disable-libgcj -- host=x86_64-redhat-linux Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-4)
> Hi guys....I've spent the whole night trying to figure out about this > question. Please help me if you have any clue. Thanks a lot.
> The code is very easy. I'm trying to call a fortran function from C.
> The code is as follow:
> =========C code========= > #include "stdio.h"
> extern float r_ (int * d, float *b);
> main () > { > float a = 1.5, b = 1.05, c = 1; > int d = 2; > c = r_ (&d, &b); > printf ("%f\n", c);
> }
> ==========Fortran Code=========== > real function r(m,t) > integer m > real t
> print *, m, t > r = 0.1*t+46 > print *, r
> return > end > ================================
> It doesn't matter what the fortran code does...but when I compile it > with g77, the result can't be passed back to the C code, but with > gfortran, it can. > [du@brutus qr]$ g77 -v ... > gcc version 3.4.6 20060404 (Red Hat 3.4.6-4) > [du@brutus qr]$ gfortran -v ... > gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
> [du@brutus qr]$ gcc -v ... > gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
1. Your g77 and gcc are of two different generations. 2. At some point g77 diverged from gfortran. They no longer (IIRC) have the same calling conventions. 3. Who cares? Is there a compelling reason to use g77, which is no longer actively maintained, instead of gfortran, which is under active development?
Good question. I'm trying to use g77 because i'm trying to develop some fortran77-only code. Of course yes i can go with gfortran. I was just curious to see the reason.
Thanks.
On May 5, 11:26 pm, e p chandler <e...@juno.com> wrote:
> > main () > > { > > float a = 1.5, b = 1.05, c = 1; > > int d = 2; > > c = r_ (&d, &b); > > printf ("%f\n", c);
> > }
> > ==========Fortran Code=========== > > real function r(m,t) > > integer m > > real t
> > print *, m, t > > r = 0.1*t+46 > > print *, r
> > return > > end > > ================================
> > It doesn't matter what the fortran code does...but when I compile it > > with g77, the result can't be passed back to the C code, but with > > gfortran, it can. > > [du@brutus qr]$ g77 -v > ... > > gcc version 3.4.6 20060404 (Red Hat 3.4.6-4) > > [du@brutus qr]$ gfortran -v > ... > > gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
> > [du@brutus qr]$ gcc -v > ... > > gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
> 1. Your g77 and gcc are of two different generations. > 2. At some point g77 diverged from gfortran. They no longer (IIRC) > have the same calling conventions. > 3. Who cares? Is there a compelling reason to use g77, which is no > longer actively maintained, instead of gfortran, which is under active > development?
In article <5065dea5-eb9e-4b0c-9413-04252b88e...@34g2000hsh.googlegroups.com>,
K-9 <rick.peng...@gmail.com> wrote: >Good question. I'm trying to use g77 because i'm trying to develop >some fortran77-only code. Of course yes i can go with gfortran. I was >just curious to see the reason.
Check out the f2c-abi. On x86 and x86-64, this is the difference between g77 and gfortran's calling conventions.
e p chandler wrote: > 2. At some point g77 diverged from gfortran. They no longer (IIRC) > have the same calling conventions.
I don't remember the exact set of options required, but I believe one can make gfortran use the g77 calling convention. I don't think it's the default, though.
In article <482096a8$0$9832$a7261...@news.hal-pc.org>, Craig Powers <eni...@hal-pc.org> writes:
> e p chandler wrote: >> 2. At some point g77 diverged from gfortran. They no longer (IIRC) >> have the same calling conventions.
> I don't remember the exact set of options required, but I believe one > can make gfortran use the g77 calling convention. I don't think it's > the default, though.
-ff2c is the option. g77's calling convention is actually the f2c calling convention bacause Craig Burley re-used the f2c run-time library.
>>Good question. I'm trying to use g77 because i'm trying to develop >>some fortran77-only code. Of course yes i can go with gfortran. I was >>just curious to see the reason.
> Check out the f2c-abi. On x86 and x86-64, this is the difference between > g77 and gfortran's calling conventions.
In that case, does this declaration fix the OP's code:
extern double r_ (int * d, float *b);
i.e., in the C code, declare the return value to be double, but maintain the "real function r(m,t)" definition in the Fortran code compiled by g77.
Chip
-- Charles M. "Chip" Coldwell "Turn on, log in, tune out" GPG Key ID: 852E052F GPG Key Fingerprint: 77E5 2B51 4907 F08A 7E92 DE80 AFA9 9A8F 852E 052F
K-9 wrote: > Good question. I'm trying to use g77 because i'm trying to develop > some fortran77-only code. Of course yes i can go with gfortran. I was > just curious to see the reason.
> Thanks.
Real functions have always been bizarre for reasons I never quite understood, but which had to do with there being no standard convention for how the return value is passed. Even in otherwise compatible object files made by two different compilers they might not work.
At the point that I discovered this particular little weirdity, I just gave up using them in mixed language programming - it wasn't worth the hassle of never knowing if they would work.
Catherine. -- Catherine Rees Lay
Polyhedron Software Ltd. Registered Office: Linden House, 93 High St, Standlake, Witney, OX29 7RH, United Kingdom. Registered in England No.2541693. Vat Reg No. GB 537 3214 57
e p chandler wrote: > 3. Who cares? Is there a compelling reason to use g77, which is no > longer actively maintained, instead of gfortran, which is under active > development?
Yes, there is. For F77 code g77 is by far faster than gfortran. I found a factor of about three for one oy my simulation programs (I can't remember which, but most probably something with N-body calculations). If compiled with g77 it took about 20 seconds for a test run. The same code, but compiled with gfortran, needed about 70 sec. As far as I remebmer, the ratio was not really better with optimisation options (BTW, what is the reason for that?).
On May 13, 2:09 pm, Ingo Thies <ingo.th...@gmx.de> wrote:
> e p chandler wrote: > > 3. Who cares? Is there a compelling reason to use g77, which is no > > longer actively maintained, instead of gfortran, which is under active > > development?
> Yes, there is. For F77 code g77 is by far faster than gfortran. I found > a factor of about three for one oy my simulation programs (I can't > remember which, but most probably something with N-body calculations). > If compiled with g77 it took about 20 seconds for a test run. The same > code, but compiled with gfortran, needed about 70 sec. As far as I > remebmer, the ratio was not really better with optimisation options > (BTW, what is the reason for that?).
> Ingo
What version of gfortran did you use for this? If you can share your code and the input, that'd be much appreciated. gfortran should be at least as good as g77 for Fortran 77 code, and usually better. If you have an example where this isn't so, I'd like to help figuring out the issue, and hopefully fix it.
stevenb....@gmail.com wrote: > What version of gfortran did you use for this? If you can share your
I can't remember, its some time (maybe even 1-2 years or so). Currently, I have g77 from gcc 3.4.6 and gfortran from gcc 4.3.1, both running on a 2 GHz AMD machine.
I have repeated the test with a program I use (mainly doing test particles in a static gravitational potential), and now the gfortran-compiled binary is only a few per cent slower than the g77 version (11.0 instead of 10.1 seconds, CPU time), both with -O4. Without optimisation option and to my big surprise the g77 version takes about twice as long as the gfortran version (40 vs. 20 secs).
Another program (pure N-body simulation with body-body interaction) takes 14.2 s/18.7 s CPU time with g77/gfortran without optimisation, and 7.9 s/9.8 s (g77/gfortran) with the -O4 option. Thus, in both cases gfortran-compiled programs are significantly (but, however, not dramatically) slower than g77-compiled ones. OK, which compiler makes the faster program naturally depends on the kind of the program. While the first program does mainly number-crunching, the second one also does many nested loops. The integration routine is the same on both cases.
In the past I have made the experience that some newer GCC versions were slightly slower than older ones (of no compiler option is chosen), but this seems to depend on the platform. On a Windows 2000 (or NT) computer there was a giant drop in speed from the gcc 2.* to the gcc 3.* version of g77, but this might be related to the distribution (the older g77 was a standalone version while the newer one came along with Cygwin, someone else had installed on the machine. I have never used Cygwin). On Linux there seems to be little difference.
However, some old third-party codes contain statements from F77 standard that are invalid in gfortran (e.g. the ugly PAUSE statement), thus causing gfortran to output a screen full of warnings.
