current status of gfortran vs g95
anal...@hotmail.com
gfortran and I did.
It ran a "hello world" program fine, supported integer*8 and the bound
checking flag works fine.
Thats very cursory testing of course - I would love to hear others'
comments and also where do gfortran and g95 stand in relation to each
other currently.
Uno
I've used both over the last several years. The scenario that happened
at least twice is that I installed g95 to check something, and it mucked
up my ability use gcc. I think Elliot Chandler has spoken to what you
need to do to avoid this problem, but I avoid it permanently by
switching to ubuntu as a platform.
I searched for g95 as a package and got nothing. Andy Vaught is, as far
as I know, less than completely engaged in the effort. I'm hoping it
turns up again as g03 or better, and delusionally, g08.
--
Uno
steve
wrote:
> I tried f95 on a linux work station and it suggested I download
> gfortran and I did.
>
> It ran a "hello world" program fine, supported integer*8 and the bound
> checking flag works fine.
>
> Thats very cursory testing of course
ROTFL.
> - I would love to hear others'
> comments and also where do gfortran and g95 stand in relation to each
> other currently.
http://www.polyhedron.com/compare0html
google "Ian Chivers Fortran comparison"
--
steve
James Van Buskirk
news:1b1751d0-13f6-4093...@v6g2000prd.googlegroups.com...
> http://www.polyhedron.com/compare0html
I couldn't find any mention there of the reason I switched from g95
to gfortran: gfortran can produce 64-bit Windows binaries, g95 can't.
I'm not sure that a gfortran version producing 64-bit binaries was
tested. For example http://www.polyhedron.com/pb05-win32-language0html
says gfortran supports only integer and logical kinds 1, 2, 4, and 8
but:
C:\gfortran\clf\kinds>type kinds.f90
program kinds
implicit none
integer, parameter :: sp = kind(1.0)
integer, parameter :: dp = kind(1.0d0)
integer, parameter :: ep_preferred = &
selected_real_kind(precision(0.0_dp)+1)
integer, parameter :: ep = (1+sign(1,ep_preferred))/2*ep_preferred+ &
(1-sign(1,ep_preferred))/2*dp
integer, parameter :: qp_preferred = &
selected_real_kind(precision(0.0_ep)+1)
integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ &
(1-sign(1,qp_preferred))/2*ep
integer, parameter :: ik1 = selected_int_kind(2)
integer, parameter :: ik2 = selected_int_kind(4)
integer, parameter :: ik4 = selected_int_kind(9)
integer, parameter :: ik8_preferred = selected_int_kind(18)
integer, parameter :: ik8 = (1+sign(1,ik8_preferred))/2*ik8_preferred+ &
(1-sign(1,ik8_preferred))/2*ik4
integer, parameter :: ik16_preferred = selected_int_kind(38)
integer, parameter :: ik16 = (1+sign(1,ik16_preferred))/2*ik16_preferred+
&
(1-sign(1,ik16_preferred))/2*ik8
write(*,10) 'sp = ', sp, ', precision(sp) = ', precision(1.0_sp)
write(*,10) 'dp = ', dp, ', precision(dp) = ', precision(1.0_dp)
write(*,10) 'ep = ', ep, ', precision(ep) = ', precision(1.0_ep)
write(*,10) 'qp = ', qp, ', precision(qp) = ', precision(1.0_qp)
write(*,10) 'ik1 = ', ik1, ', range(ik1) = ', range(1_ik1)
write(*,10) 'ik2 = ', ik2, ', range(ik2) = ', range(1_ik2)
write(*,10) 'ik4 = ', ik4, ', range(ik4) = ', range(1_ik4)
write(*,10) 'ik8 = ', ik8, ', range(ik8) = ', range(1_ik8)
write(*,10) 'ik16 = ', ik16, ', range(ik16) = ', range(1_ik16)
write(*,20) 'Testing LOGICAL(.TRUE.,ik1) = ', LOGICAL(.TRUE.,ik1)
write(*,20) 'Testing LOGICAL(.TRUE.,ik2) = ', LOGICAL(.TRUE.,ik2)
write(*,20) 'Testing LOGICAL(.TRUE.,ik4) = ', LOGICAL(.TRUE.,ik4)
write(*,20) 'Testing LOGICAL(.TRUE.,ik8) = ', LOGICAL(.TRUE.,ik8)
write(*,20) 'Testing LOGICAL(.TRUE.,ik16) = ', LOGICAL(.TRUE.,ik16)
10 format(3(a,i0))
20 format(a,L1)
end program kinds
C:\gfortran\clf\kinds>gfortran kinds.f90 -okinds
C:\gfortran\clf\kinds>kinds
sp = 4, precision(sp) = 6
dp = 8, precision(dp) = 15
ep = 10, precision(ep) = 18
qp = 10, precision(qp) = 18
ik1 = 1, range(ik1) = 2
ik2 = 2, range(ik2) = 4
ik4 = 4, range(ik4) = 9
ik8 = 8, range(ik8) = 18
ik16 = 16, range(ik16) = 38
Testing LOGICAL(.TRUE.,ik1) = T
Testing LOGICAL(.TRUE.,ik2) = T
Testing LOGICAL(.TRUE.,ik4) = T
Testing LOGICAL(.TRUE.,ik8) = T
Testing LOGICAL(.TRUE.,ik16) = T
C:\gfortran\clf\kinds>gfortran -v
Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/gcc_equation/bin/../libexec/gcc/x86_64-pc-mingw32/4.6.0/l
to-wrapper.exe
Target: x86_64-pc-mingw32
Configured with: ../gcc-4.6-20100626-mingw/configure
CFLAGS=-O0 --host=x86_64-pc
-mingw32 --build=x86_64-unknown-linux-gnu --target=x86_64-pc-mingw32 --prefix=/h
ome/gfortran/gcc-home/binary/mingw32/native/x86_64/gcc/4.6-20100626 --with-gmp=/
home/gfortran/gcc-home/binary/mingw32/native/x86_64/gmp --with-mpfr=/home/gfortr
an/gcc-home/binary/mingw32/native/x86_64/mpfr --with-mpc=/home/gfortran/gcc-home
/binary/mingw32/native/x86_64/mpc --with-sysroot=/home/gfortran/gcc-home/binary/
mingw32/cross/x86_64/gcc/4.6-20100626 --with-gcc --with-gnu-ld --with-gnu-as
--d
isable-shared --disable-nls --disable-tls --enable-libgomp --enable-languages=c,
fortran,c++ --enable-threads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.6.0 20100626 (experimental) (GCC)
shows that the 64-bit binary generating versions support also kind=16.
I think it would be useful to have a page for both 32-bit and 64-bit
binaries on the Intel Core i7 920,
http://www.polyhedron.com/pb05-win32-f90bench_p40html . I think the
performance of the 2 kinds of binary might differ significantly and
it would also enable the consumer to tell at a glance which
compilers are 64-bit capable, which I think is a more important
consideration for Fortran programmers than most other languages
because we tend to want really big data sets sometimes.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
steve
> "steve" <kar...@comcast.net> wrote in message
>
> news:1b1751d0-13f6-4093...@v6g2000prd.googlegroups.com...
>
> >http://www.polyhedron.com/compare0html
>
> I couldn't find any mention there of the reason I switched from g95
> to gfortran: gfortran can produce 64-bit Windows binaries, g95 can't.
> I'm not sure that a gfortran version producing 64-bit binaries was
> tested.
The version of gfortran (and possibly g95) tested by Polyhedron
is ancient. I expect neither the gfortran nor g95 compiler listed
at Polyhedron to be competitive with newer versions of gfortran.
--
steve
anal...@hotmail.com
OK - the machine I wnat to run fortran on is also running ubuntu - so
it looks like gfortran is the only choice in that case and judging
from the other comments, thats fine.
Janus Weil
> OK - the machine I wnat to run fortran on is also running ubuntu - so
> it looks like gfortran is the only choice in that case and judging
> from the other comments, thats fine.
It may not be the only choice, but it certainly is a good one ...
Cheers,
Janus
Carlie Coats
One differerence, significant if you do parallel computing:
g95 does co-arrays; gfortran does OpenMP.
Carlie Coats
steve
gfortran has partial support for co-arrays. See
http://gcc.gnu.org/wiki/Fortran2008Status
--
steve
GianLuigi Piacentini
I'm running Kubuntu 10.04 (the KDE version of ubuntu) and g95 ver.
0.92, which I downloaded from the g95 web site. Unfortunately I do not
have the package, I seem to remember that it was not in .deb format,
but a .tar.gz or something like that. The g95 web site has some hint
to installing the compiler, again I do not remember well where they are
... Anyway if I succeded in the installation, you should, too.
Gigi Piacentini
Gib Bogle
Can some kind soul suggest the best way to install gfortran (and gcc) on a
Windows 7 machine? I'm lost in a twisty turny maze of instructions on the MinGW
site.
gmail-unlp
Hi,
Maybe you'll find useful the posts under the topic "a wiki entry for
gfortran" (Aug. 6-16)
Fernando.
Gib Bogle
Thanks Fernando. I followed your suggestion, went to the tdm-gcc site and
downloaded the On-demand Installer, tdm-gcc-webdl.exe. With this I installed
the basic tdm-gcc package (64-bit). So far so good. Now I'm wondering how to
use this installer to add the optional packages, gfortran in particular.
gfortran doesn't come up in the list of optional software when the installer is
executed. Do you think one has to manually downlaod the gfortran files and copy
them into the mingw64 directory?
jfh
I have used both on unix/linux systems. I have found more bugs in g95
over the years than in gfortran, but most of them were fixed very
fast. As I use a system on which other people maintain gcc, I usually
find when reporting a gfortran bug that it has been fixed in a gcc
version later than the one I have access to. I also use Intel Fortran
aka ifort, and Sun f95 (and on occasion I have found and reported bugs
in both). When all four compilers give the same output and no error
messages I begin to suspect I may have a standard-conforming program,
although more work is needed to show that it does what I wanted it to
do rather than what I told it to do :-)
-- John Harper
Gib Bogle
> ... more work is needed to show that it does what I wanted it to
> do rather than what I told it to do :-)
Very specialized software is needed to achieve this.
baf
Follow the link on this line
Unofficial build of current development (4.6) source. Download the
latest installer (dated 2010-06-20). It's very easy to use (basically,
just click on the OK buttons), but some detailed info is also
available. These binaries are known to work on Windows XP, and known to
fail on Windows 98. They probably work for versions above 98.
At this site
e p chandler
"Gib Bogle" <g.b...@auckland.no.spam.ac.nz> wrote in message
news:i54c04$thn$1...@speranza.aioe.org...
Run the installer a second time and see what comes up. If the 64 bit install
is like the 32 bit install this should work.
Gib Bogle
I thought that might be the case, too, but in fact on rerunning the installer it
shows the same options, i.e. what I've already installed. Note that I'm using
the On Demand installer, not the Bundle installer. Anyway, the manual install
of other components is easy enough - I have gfortran and OpenMp installed.
gmail-unlp
I'm rather late, but it's good to know how it worked for you. I'm sure
I downloaded the so called "Bundle Installer" mainly because it's
explicitly made clear it's "The easiest install"... yes, I'm not an
expert in Windows development, as I posted in that topic ("a wiki
entry...") I make most of my work in Linux, and I'm a plain Windows
user... Anyway, with the bundle installer I requested to install every
available language, i.e. including Fortran (for which gfortran is
installed), and it worked ok. Many people posting in this forum
prefer other packages, mostly from equation.com, but I didn't have
time to check. I came to a "stable enough for checking little
examples" installation of Code::Blocks + gcc + gfortran (both
including OpenMP), and that's enough for me so far.
Fernando.
Giorgio Pastore
versions of gfortran. I'll be glad to know about other experiences.
At least in the past, fiddling with names it was possible to access
module variables from gdb debugger if the program was compiled with g95
but not with gfortran.
Moreover, g95 provides some checkpoint/restart mechanism which may be
useful.
In most of the cases I have compared the two compilers, gfortran
optimization looks better and the resulting executable run significantly
faster.
Giorgio
Gib Bogle
...
> I'm rather late, but it's good to know how it worked for you. I'm sure
> I downloaded the so called "Bundle Installer" mainly because it's
> explicitly made clear it's "The easiest install"... yes, I'm not an
> expert in Windows development, as I posted in that topic ("a wiki
> entry...") I make most of my work in Linux, and I'm a plain Windows
> user... Anyway, with the bundle installer I requested to install every
> available language, i.e. including Fortran (for which gfortran is
> installed), and it worked ok. Many people posting in this forum
> prefer other packages, mostly from equation.com, but I didn't have
> time to check. I came to a "stable enough for checking little
> examples" installation of Code::Blocks + gcc + gfortran (both
> including OpenMP), and that's enough for me so far.
>
> Fernando.
>
I'm interested in your experience with Code::Blocks, since on the web site they
mention only C compilers. If it's easy to get it working with both gcc and
gfortran it sounds like a very useful tool for multi-platform development.
gmail-unlp
Well, not too much experience... but I have to say I've installed
Code::Blocks + gcc + gfortran (both including OpenMP) without trouble
some months ago. My step-by-step procedure (at least what I recorded)
is
A) Install g-compilers (I've used only gcc and gfortran as mentioned
earlier)
B) The install (at least the one I made) includes $MINGW_ROOT/bin in
the PATH, but I had to include (manually) $MINGW_ROOT\lib\gcc
\mingw32\bin, which is the path to libgomp-1.dll in particular
C) Install Code::Blocks IDE downloaded from www.codeblocks.org
D) So far, "Console application" Code::Blocks projects work ok
E) For code with OpenMP, some minor settings are necessary in a
Code::Blocks project
Project --> Build options... (project name selected in the left panel)
Compiler settings --> Other options: -fopenmp
Linker settings --> Other linker options: -fopenmp
And the projects compile/link/run as expected (remember I've not
developed a lot of software)
And this is all I've made, along with some simple examples/programs
with OpenMP in Fortran and C. I've not installed/used Code::Blocks in
Linux.
Fernando.
user1
>
> Can some kind soul suggest the best way to install gfortran (and gcc) on
> a Windows 7 machine? I'm lost in a twisty turny maze of instructions on
> the MinGW site.
it is a bit tricky finding the right page at Mingw site. The manual
installation instructions on the "Getting Started" page worked for me.
Clive Page
<277b9d9d-17df-410a...@f6g2000pro.googlegroups.com>, jfh
<john....@vuw.ac.nz> writes
>I have used both on unix/linux systems. I have found more bugs in g95
>over the years than in gfortran, but most of them were fixed very
>fast. As I use a system on which other people maintain gcc, I usually
>find when reporting a gfortran bug that it has been fixed in a gcc
>version later than the one I have access to. I also use Intel Fortran
>aka ifort, and Sun f95 (and on occasion I have found and reported bugs
>in both). When all four compilers give the same output and no error
>messages I begin to suspect I may have a standard-conforming program,
>although more work is needed to show that it does what I wanted it to
>do rather than what I told it to do :-)
That is very good advice. I use both on Linux systems and NAG f95 and
sometimes Intel ifort too. I use both g95 and gfortran on Windows XP. I
don't know about other people, but I always write programs that turn out
to have bugs in them. I find each compiler finds some of my mistakes
that the other(s) do not. Like John, when all of them give no errors
and the same results, I think I'm getting to the point that my program
is portable and maybe even good enough to use. Of course no large
program is ever totally bug-free.
On the whole I find g95 just slightly better in its diagnostics -
especially the traceback from run-time errors when code is compiled with
-ftrace=full. There is even an optional message to nag you about
failing to deallocate something on program termination that you
allocated earlier. I don't see anything quite as good as these in the
gfortran options, but maybe I just didn't look in the right place.
--
Clive Page
Tobias Burnus
> On the whole I find g95 just slightly better in its diagnostics -
> especially the traceback from run-time errors when code is compiled with
> -ftrace=full.
On Linux, you could try "-fbacktrace -g" with gfortran. It uses GLIBC's
rewinding facility thus it does not work under Windows. (Though, it
might work with Cygwin). Otherwise, try -fdump-core and run the program
in the debugger - then you can use the debugger print the backtrace.
(Frankly, I never got g95 -ftrace=full working on x86-64 Linux - it
never printed anything. Either my programs crashed too hard for g95's
backtracing or possibly it is using frame pointers, which are not
available under x86-64. Does -ftrace=full work for someone else under
x86-64?)
> There is even an optional message to nag you about failing
> to deallocate something on program termination that you allocated
> earlier.
Note: Since Fortran 95 (possibly also since Fortran 90 though the
wording was not as clear) Fortran automatically deallocates ALLOCATABLEs
when leaving the scope - thus the warning does only make sense for POINTER.
It is still considered adding such a facility to gfortran, cf.
http://gcc.gnu.org/ml/fortran/2009-04/msg00226.html - though, it is
unclear when this will happen. Maybe, when most Fortran 2003/2008 have
been implemented?
Tobias
Gib Bogle
...
> Well, not too much experience... but I have to say I've installed
> Code::Blocks + gcc + gfortran (both including OpenMP) without trouble
> some months ago. My step-by-step procedure (at least what I recorded)
> is
>
> A) Install g-compilers (I've used only gcc and gfortran as mentioned
> earlier)
>
> B) The install (at least the one I made) includes $MINGW_ROOT/bin in
> the PATH, but I had to include (manually) $MINGW_ROOT\lib\gcc
> \mingw32\bin, which is the path to libgomp-1.dll in particular
>
> C) Install Code::Blocks IDE downloaded from www.codeblocks.org
>
> D) So far, "Console application" Code::Blocks projects work ok
From this I guess that Code::Blocks detected gfortran automagically.
What I'm particularly interested in (apart from the Fortran side) is the
possibility of building Qt applications with Code::Blocks.
Clive Page
writes
>(Frankly, I never got g95 -ftrace=full working on x86-64 Linux - it
>never printed anything. Either my programs crashed too hard for g95's
>backtracing or possibly it is using frame pointers, which are not
>available under x86-64. Does -ftrace=full work for someone else under
>x86-64?)
I just tried g95 on a linux x86-64 box and it seemed to work for me (but
it took 3 attempts for me to introduce a suitable error in my code, I
must be out of practice :-)
ardbeg:~> g95 -ftrace=full tracetest.f90
ardbeg:~> a.out
At line 31 of file tracetest.f90 file: "null"
Traceback: (Innermost first)
Called from line 6 of file tracetest.f90
Fortran runtime error: No such file or directory
>Note: Since Fortran 95 (possibly also since Fortran 90 though the
>wording was not as clear) Fortran automatically deallocates
>ALLOCATABLEs when leaving the scope - thus the warning does only make
>sense for POINTER.
If you allocate something in the main program, but never deallocate it,
I guess it's still allocated when you execute STOP. But it isn't a
warning that I've ever found useful, rather an annoyance in fact, so the
lack of it in gfortran is in fact a slight advantage, in my opinion.
>It is still considered adding such a facility to gfortran, cf.
>http://gcc.gnu.org/ml/fortran/2009-04/msg00226.html - though, it is
>unclear when this will happen. Maybe, when most Fortran 2003/2008 have
>been implemented?
When hell freezes over, would be my suggestion.
--
Clive Page
gmail-unlp
Sorry, my mistake, this is true only for gcc (mingw gcc is
automagically detected - from PATH settings, I think). I was verifying
my Code::Blocks installations and all I have are C/C++ projects (well,
a few of them). In some of the same computers I've run Fortran using
gfortran (from the same installation/directories), but not through
Code::Blocks but directly in the command line. Of course, there is
some information via google, but I didn't have time to check. If
someone has
information or knows the procedure, please post.
Fernando.
glen herrmannsfeldt
(snip)
> If you allocate something in the main program, but never deallocate it,
> I guess it's still allocated when you execute STOP. But it isn't a
> warning that I've ever found useful, rather an annoyance in fact, so the
> lack of it in gfortran is in fact a slight advantage, in my opinion.
Fortran 2003, 6.3.3.1:
"When the execution of a procedure is terminated by execution
of a RETURN or END statement, an allocatable variable that is
a named local variable of the procedure retains its allocation
and definition status if it has the SAVE attribute or is a
function result variable or a subobject thereof; otherwise, it
is deallocated."
A warning in the cases where it is not deallocated makes some sense.
If one later converts the main program into a subroutine, it is
nice to deallocate variables that are otherwise not needed.
Otherwise, a protected mode operating system should deallocate all
memory allocated to a task when that task terminates.
-- glen
Gib Bogle
> Sorry, my mistake, this is true only for gcc (mingw gcc is
> automagically detected - from PATH settings, I think). I was verifying
> my Code::Blocks installations and all I have are C/C++ projects (well,
> a few of them). In some of the same computers I've run Fortran using
> gfortran (from the same installation/directories), but not through
> Code::Blocks but directly in the command line. Of course, there is
> some information via google, but I didn't have time to check. If
> someone has
> information or knows the procedure, please post.
It's a simple matter to get CB to use gfortran - you just pretend that it's a C
compiler.
stevenb
> Maybe the following observation has already been overcome by the latest
> versions of gfortran. I'll be glad to know about other experiences.
>
> At least in the past, fiddling with names it was possible to access
> module variables from gdb debugger if the program was compiled with g95
> but not with gfortran.
A lot of work was put into both GDB and gfortran 4.5.1 to make GDB
understand Fortran module variables. I can't say I've tested it
myself, but you may want to give it a try.
Ciao!
Steven
Tobias Burnus
To get access to module variable, I think you need a fairly recent GDB;
I forgot whether the support is already available in 7.1 or has been
added only later - it is definitely in GDB 7.2 (which has not yet been
released).
For support to assumed-shape and deferred-shape arrays (and C's variable
length arrays), you need to use Jan Kratochvil's pathes, cf.
http://sourceware.org/gdb/wiki/ArcherBranchManagement
Or Fedora's (or openSUSE's) gdb. Maybe there are also other
distributions, which use Jan's patches.
Tobias