A few quick questions about gfortran under cygwin

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 -lgfortra
n
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 -lgfortra
n
-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, CER
N
KotPT -- "for stupidity above and beyond the call of duty".

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

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:
 

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

Thanks Tim, I'll try that at first opporunity.

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

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 particu
larly
challenging.  However it did find a few non-Standard items in my code that n
eeded
cleaning up, which had previously gone unnoticed.  Not going to say what the
y 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 emai
l
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, a
nd
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 versi
on
I need to recompile the gcc world.  Maybe kick it off before work today.  Su
re
would be nice if the gfortran folk would update the cygwin binaries...

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

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 parti
cularly
> 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 t
hey 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 em
ail
> archives, it seems the mixing of INTEGER/LOGICAL is going to be implemente
d
> soon.  This is a true horror which should only be enabled with some sort o
f
> -badly_broken_code option.)  IMHO it is better to keep the compiler clean,
 and
> issue diagnostics - by default - than to silently compile known error-pron
e
> '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/

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 parti
cularly
> 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 t
hey 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 em
ail
> archives, it seems the mixing of INTEGER/LOGICAL is going to be implemente
d
> soon.  This is a true horror which should only be enabled with some sort o
f
> -badly_broken_code option.)  IMHO it is better to keep the compiler clean,
 and
> issue diagnostics - by default - than to silently compile known error-pron
e
> '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.

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-co
nforming
and what is not.  And my observations are that many will never specify non-d
efault
compilation options unless dragged kicking and screaming.  So, IMHO, it is p
retty important
to very carefully, thoughtfully, and conservatively sort out what sorts of e
xtensions are
both useful and add to the quality the code base (e.g, adding F2003 capabili
ties should
be regarded as a Good Thing.)  As opposed to blindly trying to make sense ou
t 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 ri
ght 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)

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:
 

> 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, CER
N
KotPT -- "for stupidity above and beyond the call of duty".