COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

### weird g77 and gfortran

• Follow

Hi guys....I've spent the whole night trying to figure out about this

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 --
enable-checking=release --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --enable-libgcj-multifile --enable-
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
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!   0 Reply rick.peng.du (11) 5/6/2008 2:55:53 AM 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?


 0
Reply epc8 (1259) 5/6/2008 3:26:33 AM

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:
>
>
>
>
>
>
>
>
> > 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?   0 Reply rick.peng.du (11) 5/6/2008 3:35:13 AM 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   0 Reply lindahl (696) 5/6/2008 4:22:41 AM 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.   0 Reply enigma (394) 5/6/2008 5:34:32 PM 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

 0
Reply kargl (773) 5/6/2008 5:38:15 PM

lindahl@pbm.com (Greg Lindahl) writes:

> 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
GPG Key ID: 852E052F
GPG Key Fingerprint: 77E5 2B51 4907 F08A 7E92  DE80 AFA9 9A8F 852E 052F

 0
Reply coldwell7 (79) 5/7/2008 3:10:21 AM

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

 0
Reply catherine.news (58) 5/7/2008 8:47:42 AM

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

 0
Reply ingo.thies (51) 5/13/2008 12:09:52 PM

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

 0
Reply stevenb.gcc (19) 5/13/2008 12:50:59 PM

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

 0
Reply ingo.thies (51) 5/13/2008 2:16:31 PM

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

 0
Reply kargl (773) 5/13/2008 2:36:29 PM

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.

 0
Reply tkoenig1 (168) 5/13/2008 6:24:21 PM

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


 0
Reply lindahl (696) 5/13/2008 6:55:07 PM

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

 0
Reply ingo.thies (51) 5/14/2008 12:37:54 PM

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.

 0
Reply tkoenig1 (168) 5/15/2008 4:48:20 PM

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

 0
Reply ingo.thies (51) 5/16/2008 8:20:17 AM

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

 0
Reply stevenb.gcc (19) 5/16/2008 10:57:03 PM

17 Replies
105 Views