Fortran - A few quick questions about gfortran under cygwin

Author

A few quick questions about gfortran under cygwin

Dr Ivan D. Reid

2005-05-31, 8:58 pm

a) What's the latest binary version available? All I found was
GNU F95 version 4.1.0 20050320 -- I thought there should be something later.

b) I've seen mention of compiling it oneself, but no instructions on how
to do it. Are they available anywhere?

c) How do I stop it trying to reference the D: drive? I have a problem
with the DVD+RW on my laptop, in that it takes ages to do any directory
operation (about a 30 second time-out) and my first attempts at compiling
a programme took ages until I thought the problem through and popped open
the DVD drawer. Output of a compile follows, note the --prefix flag.
I tried over-riding that with my own flag, but that did not help.

Ivan@IDRLAP02 ~/fortran
$ /usr/local/gcc4/bin/gfortran.exe -v sudoku3.f
Driving: /usr/local/gcc4/bin/gfortran -v sudoku3.f -lgfortranbegin -lgfortran
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc-4.1-20050320/configure --prefix=/cygdrive/d/irun41
--with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp
--enable-languages=c,c++,f95,java
Thread model: single
gcc version 4.1.0 20050320 (experimental)
/usr/local/gcc4/bin/../libexec/gcc/i686-pc-cygwin/4.1.0/f951.exe sudoku3.f
-ffixed-form -quiet -dumpbase sudoku3.f -mtune=pentiumpro -auxbase sudoku3
-version -o /cygdrive/c/DOCUME~1/Ivan/LOCALS~1/Temp/ccHcLUjO.s
GNU F95 version 4.1.0 20050320 (experimental) (i686-pc-cygwin)
compiled by GNU C version 3.2 20020927 (prerelease).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
as -o /cygdrive/c/DOCUME~1/Ivan/LOCALS~1/Temp/cc9L8ERm.o
/cygdrive/c/DOCUME~1/Ivan/LOCALS~1/Temp/ccHcLUjO.s
/usr/local/gcc4/bin/../libexec/gcc/i686-pc-cygwin/4.1.0/collect2.exe
-Bdynamic --dll-search-prefix=cyg /lib/crt0.o
-L/usr/local/gcc4/bin/../lib/gcc/i686-pc-cygwin/4.1.0
-L/usr/local/gcc4/bin/../lib/gcc
-L/usr/local/gcc4/bin/../lib/gcc/i686-pc-cygwin/4.1.0/../../..
/cygdrive/c/DOCUME~1/Ivan/LOCALS~1/Temp/cc9L8ERm.o -lgfortranbegin -lgfortran
-lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc

--
Ivan Reid, Electronic & Computer Engineering, ___ CMS Collaboration,
Brunel University. Ivan.Reid@brunel.ac.uk Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".

Tim Prince

2005-06-01, 3:57 am

Dr Ivan D. Reid wrote:

>
> b) I've seen mention of compiling it oneself, but no instructions on how
> to do it. Are they available anywhere?
>
http://gcc.gnu.org/wiki/GFortran

Grab the source version of your choice, follow gcc build instructions at
gcc.gnu.org. Minimum build is C and f95:

set appropriate compile flags, e.g.
export CFLAGS='-O2 -march=pentium-m -pipe -g'
export BOOT_CFLAGS='-O2 -march=pentium-m -pipe'

default install prefix is /usr/local/
refer to the configure flags posted on gcc-testresults,typically
.../configure --enable-threads=posix
--enable-sjlj-exceptions --disable-libmudflap --enable-languages=f95

make bootstrap-lean
make -k check
make install

--
Tim Prince

Dr Ivan D. Reid

2005-06-01, 9:03 am

Walter Spector

2005-06-01, 4:00 pm

Tim Prince wrote:
> ...
> Grab the source version of your choice, follow gcc build instructions at
> gcc.gnu.org. Minimum build is C and f95...

I finally decided to download a copy of gfortran last night. Started with
the cygwin version of the binaries, which have not been updated since march.
Got the 'illegal instruction' error, which was reported in the gfortran mail
archives from around then. (FWIW, the computer I loaded it on has a lowly
Pentium III in it.)

Downloaded the windows version and it actually works - sort of. It doesn't
know about the cygwin dlls, so a lot of my 'system call'ish code does not
easily link up.

Gfortran did compile about 6k lines of that I threw at it. Most not particularly
challenging. However it did find a few non-Standard items in my code that needed
cleaning up, which had previously gone unnoticed. Not going to say what they are,
because otherwise someone associated with gfortran might 'fix' them...

I would really hope the gfortran folk would resist the urge for total
bug/backward-compatibility with g77. Some of those old extensions just
introduce hard-to-find errors into codes. (One example: scanning the email
archives, it seems the mixing of INTEGER/LOGICAL is going to be implemented
soon. This is a true horror which should only be enabled with some sort of
-badly_broken_code option.) IMHO it is better to keep the compiler clean, and
issue diagnostics - by default - than to silently compile known error-prone
'extensions'.

It any event, this is neat. But it seems that if I need a true cygwin version
I need to recompile the gcc world. Maybe kick it off before work today. Sure
would be nice if the gfortran folk would update the cygwin binaries...

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

Steven G. Kargl

2005-06-01, 4:00 pm

In article <429DB45C.52432279@earthlink.net>,
Walter Spector <w6ws_xthisoutx@earthlink.net> writes:
>
> Gfortran did compile about 6k lines of that I threw at it. Most not particularly
> challenging. However it did find a few non-Standard items in my code that needed
> cleaning up, which had previously gone unnoticed. Not going to say what they are,
> because otherwise someone associated with gfortran might 'fix' them...

This is good news.

> I would really hope the gfortran folk would resist the urge for total
> bug/backward-compatibility with g77. Some of those old extensions just
> introduce hard-to-find errors into codes. (One example: scanning the email
> archives, it seems the mixing of INTEGER/LOGICAL is going to be implemented
> soon. This is a true horror which should only be enabled with some sort of
> -badly_broken_code option.) IMHO it is better to keep the compiler clean, and
> issue diagnostics - by default - than to silently compile known error-prone
> 'extensions'.

The INTEGER/LOGICAL (mis)feature was motivated by some code, which is
part of spec2000fp (or whatever the name of the SPEC floating point
benchmark). As to enabling (mis)feature, gfortran now has the following
options:

-std=f95 ----> fairly strict adherence to Fortran 95 standard.
-std=gnu ----> fairly permissive (ie., try to compile anything one throws
at gfortran). This is the default behavior.
-std=legacy -> accept common extension or deprecated features (ie. REAL
do loop index).

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

Brooks Moses

2005-06-02, 3:59 am

Walter Spector wrote:
> Downloaded the windows version and it actually works - sort of. It doesn't
> know about the cygwin dlls, so a lot of my 'system call'ish code does not
> easily link up.

Is this something that means the Windows version is broken, or merely a
result of the fact that non-cygwin programs in general don't know about
cygwin dlls on the system?

> Gfortran did compile about 6k lines of that I threw at it. Most not particularly
> challenging. However it did find a few non-Standard items in my code that needed
> cleaning up, which had previously gone unnoticed. Not going to say what they are,
> because otherwise someone associated with gfortran might 'fix' them...

Well, as Steve Kargl mentioned, gfortran is intended to have various
standard-compatibility options, such that if you prefer to have all of
the non-standard items to be diagnosed, you should tell it to use
"-std=f95". There appears, from the mailing list, to be quite a bit of
effort going into making the gfortran compiler very strict with regards
to the standard when this is specified.

> I would really hope the gfortran folk would resist the urge for total
> bug/backward-compatibility with g77. Some of those old extensions just
> introduce hard-to-find errors into codes. (One example: scanning the email
> archives, it seems the mixing of INTEGER/LOGICAL is going to be implemented
> soon. This is a true horror which should only be enabled with some sort of
> -badly_broken_code option.) IMHO it is better to keep the compiler clean, and
> issue diagnostics - by default - than to silently compile known error-prone
> 'extensions'.

I believe (though I could be misremembering) that this particular item
was the topic which prompted the implementation of a "-std=legacy"
option -- which is pretty much just a different spelling of your
"-badly_broken_code". :)

The default is definitely to issue diagnostics for this sort of thing,
though I believe they may well default to warnings rather than errors.
But this default is certainly changable, and it's possible to ask
gfortran to be quite strict if you wish it to be.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Walter Spector

2005-06-02, 3:59 am

Brooks Moses wrote:
>
> Walter Spector wrote:
>
> Is this something that means the Windows version is broken, or merely a
> result of the fact that non-cygwin programs in general don't know about
> cygwin dlls on the system?

The latter.

>
> Well, as Steve Kargl mentioned, gfortran is intended to have various
> standard-compatibility options, such that if you prefer to have all of
> the non-standard items to be diagnosed, you should tell it to use
> "-std=f95".

Of course. But my real concern is that accepting 'every extension under the sun',
by DEFAULT, does nothing to discourage the use of the more problematic ones across
the Fortran community as a whole.

There are many Fortran developers who have no clue as to what is Standard-conforming
and what is not. And my observations are that many will never specify non-default
compilation options unless dragged kicking and screaming. So, IMHO, it is pretty important
to very carefully, thoughtfully, and conservatively sort out what sorts of extensions are
both useful and add to the quality the code base (e.g, adding F2003 capabilities should
be regarded as a Good Thing.) As opposed to blindly trying to make sense out of
"pretty much anything anyone tries to throw at the compiler".

> Though even There appears, from the mailing list, to be quite a bit of
> effort going into making the gfortran compiler very strict with regards
> to the standard when this is specified.

From less than 1 day of use of gfortran, it seems that it is fairly clean right now.
So I'd hate to see the "by default" language to start getting cluttered up
like g77 and most commercial compiler are.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

Dr Ivan D. Reid

2005-06-03, 9:07 am

On Wed, 01 Jun 2005 01:57:04 GMT, Tim Prince <timothyprince@sbcglobal.net>
wrote in <QB8ne.852$IE7.532@newssvr21.news.prodigy.com>:
> Dr Ivan D. Reid wrote:

[color=darkred]
> http://gcc.gnu.org/wiki/GFortran

> Grab the source version of your choice, follow gcc build instructions at
> gcc.gnu.org. Minimum build is C and f95:

I still haven't found any explicit instructions; they seem to be
well hidden. For a while I was trying to build from an inappropriate
directory.

> set appropriate compile flags, e.g.
> export CFLAGS='-O2 -march=pentium-m -pipe -g'
> export BOOT_CFLAGS='-O2 -march=pentium-m -pipe'

> default install prefix is /usr/local/

Install bison & flex.
Install patch:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00009.html

$ find . -name config.cache -exec rm {} \;

$ mkdir obj
$ cd obj

> refer to the configure flags posted on gcc-testresults,typically
> ../configure --enable-threads=posix
> --enable-sjlj-exceptions --disable-libmudflap --enable-languages=f95

$ ../configure --prefix=/usr/local/gcc-4_1 --enable-threads=posix
--disable-libgcj --enable-sjlj-exceptions --with-system-zlib --enable-nls
--disable-libmudflap --enable-version-specific-runtime-libs
--without-included-gettext --disable-shared
--enable-languages=c,c++,f95,java

> make bootstrap-lean
> make -k check

This failed due to no autogen

> make install

$ du /usr/local/gcc-4_1/
....
118463 /usr/local/gcc-4_1/

$ ls /usr/local/gcc-4_1/
bin include info lib libexec man share

$ ls /usr/local/gcc-4_1/bin/
c++.exe gccbug gjnih.exe i686-pc-cygwin-gcc.exe
cpp.exe gcj.exe grepjar.exe i686-pc-cygwin-gcj.exe
fastjar.exe gcjh.exe i686-pc-cygwin-c++.exe i686-pc-cygwin-gcjh.exe
g++.exe gcov.exe i686-pc-cygwin-g++.exe jcf-dump.exe
gcc.exe gfortran.exe i686-pc-cygwin-gcc-4.1.0 jv-scan.exe

I now have the tree in a 32 MB .tgz file of the tree if anyone
wants to try it; mail me. I just need to find public-facing storage with
enough space.

--
Ivan Reid, Electronic & Computer Engineering, ___ CMS Collaboration,
Brunel University. Ivan.Reid@brunel.ac.uk Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".

Sponsored Links