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:

***fortran code compiled by gfortran****
[du@brutus qr]$ gfortran -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.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)

[du@brutus qr]$ gfortran -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
enable-checking=release --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --enable-libgcj-multifile --enable-
languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --
disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-
gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)


[du@brutus qr]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
enable-checking=release --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --enable-libgcj-multifile --enable-
languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --
disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-
gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)


THANKS AGAIN FOR THE HELP!

On May 5, 10:55=A0pm, K-9 <rick.peng...@gmail.com> wrote:
> 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:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3DC code=3D=3D=3D=3D=3D=3D=3D=3D=3D
> #include "stdio.h"
>
> extern float r_ (int * d, float *b);
>
> main ()
> {
> =A0 =A0 =A0float a =3D 1.5, b =3D 1.05, c =3D 1;
> =A0 =A0 =A0int d =3D 2;
> =A0 =A0 =A0c =3D r_ (&d, &b);
> =A0 =A0 =A0printf ("%f\n", c);
>
> }
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DFortran Code=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> =A0 =A0 =A0 real function r(m,t)
> =A0 =A0 =A0 integer m
> =A0 =A0 =A0 real t
>
> =A0 =A0 =A0 print *, m, t
> =A0 =A0 =A0 r =3D 0.1*t+46
> =A0 =A0 =A0 print *, r
>
> =A0 =A0 =A0 return
> =A0 =A0 =A0 end
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>
> 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
=2E..
> gcc version 3.4.6 20060404 (Red Hat 3.4.6-4)

> [du@brutus qr]$ gfortran -v
=2E..
> gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
>
> [du@brutus qr]$ gcc -v
=2E..
> 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:
> On May 5, 10:55 pm, K-9 <rick.peng...@gmail.com> wrote:
>
>
>
>
>
>
>
> > 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?

In article <5065dea5-eb9e-4b0c-9413-04252b88eff0@34g2000hsh.googlegroups.com>,
K-9  <rick.peng.du@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.

-- greg

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$a726171b@news.hal-pc.org>,
	Craig Powers <enigma@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.

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/

lindahl@pbm.com (Greg Lindahl) writes:

> In article <5065dea5-eb9e-4b0c-9413-04252b88eff0@34g2000hsh.googlegroups.com>,
> K-9  <rick.peng.du@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.

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

Ingo

On May 13, 2:09=A0pm, 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.

Gr.
Steven

stevenb.gcc@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.

-- 
Gru�,
       Ingo

In article <68tm60F2utvhrU1@mid.individual.net>,
	Ingo Thies <ingo.thies@gmx.de> writes:
> 
> 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.
> 

gfortran supports all standard Fortran 77 features.  If it doesn't 
support a feature, please file a bug report.  Receiving a warning
does not mean the Fortran 77 feature isn't supported.  It typically
means the Fortran 90/95/03 standards have marked the feature as
either obsolescent or deleted.  gfortran is simply informing you of
this development.  If you don't want to see warnings, use the -w
option.

 PS: There is no -O4 option.  The highest optimization level is 3.
PPS: With gfortran I'd suggested '-O2 -funroll-loops -march=native'
     as the compilation options.  If you want additional speed at
     the expense of correctness add -ffast-math.  Also, note -O3
     should have only a minimal impact on your code because it
     turns on more agressive in-lining, and gfortran only in-lines
     CONTAINed subprograms.

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/

Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:

> PPS: With gfortran I'd suggested '-O2 -funroll-loops -march=native'
>      as the compilation options.  If you want additional speed at
>      the expense of correctness add -ffast-math.

Using -ftree-vectorize in addition to the options above might also
be worth a try.

In article <68tm60F2utvhrU1@mid.individual.net>,
Ingo Thies  <ingo.thies@gmx.de> wrote:

>Another program (pure N-body simulation with body-body interaction) 
>takes 14.2 s/18.7 s CPU time with g77/gfortran without optimisation, 

There is no point to comparing execution time without optimization.
Compilers generate deliberately bad code at -O0 in order to help
debugging. It could be that gfortran is better for debugging than g77.

Comparing at -O1 doesn't really make sense, either, as different
compilers make different choices of what optimizations to do at -O1.
If I recall correctly, Intel is very aggressive at -O1, so the
generated code is good, but the compiler takes a relatively long time
to spit it out.

-- greg

Thomas Koenig wrote:

>> PPS: With gfortran I'd suggested '-O2 -funroll-loops -march=native'
>>      as the compilation options.  If you want additional speed at
>>      the expense of correctness add -ffast-math.
> 
> Using -ftree-vectorize in addition to the options above might also
> be worth a try.

I've tried all these options; except for the optimization level 2 itself 
there is no significant difference in speed. g77 is still slightly 
faster than gfortran in all tests.

Even -ffast-math does not have any noticable effect. As far as I 
remember, I have never noticed any difference with -ffast-math, and I 
also remember havin read that at least for g77 this option is a dummy 
option for something that might be implemented in the future. I do not 
know whether it has ever been implemented in any GNU compiler, but until 
Steven mentioned it here I would have guessed that it is still a dummy.

Or is it possible that -ffast-math only supports Intel CPUs (it might be 
that all CPUs where I have tested it were AMDs and a PowerPC Mac)?

Ingo

On 2008-05-13, Ingo Thies <ingo.thies@gmx.de> wrote:

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

\begin{wild_guess}

If you're doing n-body simulations, you might be doing lot of
sqrt calls.  There is, or used to be, an issue with sqrt on AMD
64 chips for gcc - for some reason, sqrt of a REAL is much slower
than sqrt of a DOUBLE PRECISION.

\end{wild_guess}

Otherwise, could you post sample code here or to fortran@gcc.gnu.org?
If this is a performance regression vs. g77, it should be investigated.

Thomas Koenig wrote:

> sqrt calls.  There is, or used to be, an issue with sqrt on AMD
> 64 chips for gcc - for some reason, sqrt of a REAL is much slower
> than sqrt of a DOUBLE PRECISION.

Hmm, since I usually use DOUBLE PRECISION instead of REAL in such 
simulations, this shouldn't be the reason (unless you mean double is 
slower than real).

> Otherwise, could you post sample code here or to fortran@gcc.gnu.org?
> If this is a performance regression vs. g77, it should be investigated.

I can try to create some sample code as soon as time permits.

Ingo

On May 16, 10:20 am, Ingo Thies <ingo.th...@gmx.de> wrote:
> I can try to create some sample code as soon as time permits.

That'd be much appreciated. Thanks!

Gr.
Steven