Praise for Gfortran (finally)
Al Greynolds
engineering application using simultaneously several compilers (XLF,
LF95, G95, and IVF). During that time I toyed with Gfortran and put
up with the 2 steps forward, 1 step back of each binary build.
However, I'm now happy to report my "last" issue with it has been
resolved and more importantly performance is almost identical to XLF
and IVF in most cases. Congratulations to all involved with this
project!
Al Greynolds
www.ruda.com
Damian
I'll second that. I've used roughly half a dozen compilers over the
past five years. Over the past year, gfortran really seems to be
raging ahead of a lot of the competition in features. I really hope
the Gnu Compiler Collection will ultimately assume the leadership role
in the Fortran community that it played in the C++ community a decade
ago. It's great to see volunteers accomplishing what commercial
developers can't or won't accomplish in the same amount of time.
Damian
paul.rich...@gmail.com
Many thanks for the praise - every little bit helps:-)
> > Over the last few years I have developed a 30,000 line Fortran-95
> > engineering application using simultaneously several compilers (XLF,
> > LF95, G95, and IVF). During that time I toyed with Gfortran and put
> > up with the 2 steps forward, 1 step back of each binary build.
We are sharply aware of this problem. It has come about largely
because of the inadequacy, in the past, of our testsuite. Not having
a take-the-standard-and-write-a-testsuite yardstick to go by, ours has
grown as we have fixed bugs and regressions. Thus, our random walk
through bugspace is, at least Markovian; for the main part they do
not get repeated. Also, whilst some of the things that people try to
do are "ïnteresting", the space in which we can wander seems to be
bounded too.
> > However, I'm now happy to report my "last" issue with it has been
> > resolved and more importantly performance is almost identical to XLF
> > and IVF in most cases. Congratulations to all involved with this
> > project!
>
Thanks!
>
> I'll second that. I've used roughly half a dozen compilers over the
> past five years. Over the past year, gfortran really seems to be
> raging ahead of a lot of the competition in features. I really hope
> the Gnu Compiler Collection will ultimately assume the leadership role
> in the Fortran community that it played in the C++ community a decade
> ago. It's great to see volunteers accomplishing what commercial
> developers can't or won't accomplish in the same amount of time.
I'm not entirely convinced that were are "raging ahead" but we are
trying. It has been difficult, at times, to get right the balance
between new features, both non-standard and F200x, and ensuring that
gfortran is an effective, standard-compliant F95 compiler.
Astonishingly, in spite of the sometimes anarchic tendencies of the
gfortran maintainers collective, we do seem to go in roughly the right
direction. For example, we have done the ground work for CLASSes and
OOP during 2008, which should be realised in gcc-4.5.
The constraints on commercial compiler developers are very different
to those on a volunteer group. In essence, they cannot afford the one
step back for every two forward; therefore, they take one little step
at a time:-) I suspect that we will arrive at our respective
destinations simultaneously....
One feature of the gfortran maintainers group is that there is a
fairly continuous turn-over, with a characteristic time of a few
years. Thus, we are always on the lookout for new blood. If anybody
out there is interested in joining in, please get in touch.
Thanks again for the kind remarks.
Paul
Arjen Markus
Perhaps you can describe in some detail how people can help out:
developing a compiler seems a rather daunting task and if you
can tell about the less daunting aspects and tasks you may get more
people involved.
Regards,
Arjen
Tobias Burnus
> Perhaps you can describe in some detail how people can help out:
> developing a compiler seems a rather daunting task and if you
> can tell about the less daunting aspects and tasks you may get more
> people involved.
I think the typical way one gets deeply involved with gfortran
development is as follows:
1. One starts using it and finds a bug/missing feature, which one
reports
2. One starts building gfortran oneself
3. One creates a small, simple patch, e.g. for a trivial bug or for
the documentation
4. One gets involved in fixing bugs
5. One starts writting bigger patches & reviews other patches
6. The steering committee appoints one as maintainer
(7. All the programs one uses work and one gets other work to do and
thus one mostly stops gfortran development)
Any help at either stage is welcome (though (7) less so ;-) and there
are several contributers which restrict themselves to finding bugs,
triaging bugs and testing patches (though I still have the hope some
of them will start writing patches themselves).
* * *
To get involved:
a) Very important is that bugs are reported. If you know a code which
is standard Fortran 95 and it does not work - report it; if possible
try to reduce the source code to the smallest possible which still
reproduces the problem (for proprietary code you need to do so). Same
for all internal compiler errors. Bug reports and feature requests for
Fortran 2003, (common) vendor extensions, better diagnostics etc. are
also welcome but have (naturally) a lower priority [for instance we
already know that CLASS is missing and we plan to add it in 4.5, but
better a bug report/feature request more than one too little].
Even though gfortran has a rather large test suite (94192 lines) and
it is regularly checked against some big real-world codes, benchmark
codes (CPU Spec, Polyhedron) and Fortran test suites, there are and
will be always old and new bugs (regressions), including performance
regressions. Thus doing regular tests with your most favoured codes or
the most wicked corner cases you can can up with are helpful.
Note 1: Not all bugs reported to c.l.f are found and entered in
Bugzilla; it would be nice if users reading c.l.f could also check
whether a bug report exists. If you don't like Bugzilla or are unsure,
whether to fill a bug, you can also write to the fortran insert at
sign gcc.gnu.org mailing list.
Note 2: It makes sense to use the latest developer release (currently
4.4, which is in the bug fixing stage (Stage 3) or the latest released
version (currently 4.3.x). Regressions and important bugs (with fixed
by simple patches) are fixed in 4.3.x and in 4.4, all other bugs will
only be fixed in 4.4. Version 4.2 or older are effectively not
maintained.
Especially if you have access to a non-default system, testing there
(and debugging failures) is especially appreciated as most of the
developers are only using x86 and x86-64 Linux systems, though we have
some regular MacOS PowerPC and Windows users and the test suite is run
on all kind of systems. (However, we lack developers with Windows
expertise, which is an important platform for gfortran in terms of
usage and a bit neglected.)
b) The documentation (http://gcc.gnu.org/onlinedocs/gfortran/ or
http://gcc.gnu.org/onlinedocs/gfortran.pdf ) is in a quite good shape,
but improvements are always possible. If you find an error, fill a bug
report or better create a patch. But also enhancement patches are
highly welcome.
c) If you want to start programming the compiler (and have some [more
or less basic] C knowledge): I think one can find some smaller
projects as starting point, especially accepts-invalid and diagnostic
bugs are usually not too difficult. Compared with the middle-end
compiler work, programming the front end is usually not to difficult
if one has found the way through the files. One essentially programs
like normal; only in the later parts of the compilation process when
the structure for the middle end is generated, it gets a bit more
complicated.
d) If you are really eager or you find a student who is, one can
easily find bigger projects, which might also be funded by e.g. Google
summer of code. (We had two students this year.) Though starting with
(c) makes sense.
Tobias
PS: Note that for bigger patches, the Free Software Foundation (FSF)
wants to have a copyright assignment, cf. http://gcc.gnu.org/contribute.html#legal.
Since paper-based letters are sent around, this might take a while.
Thus if you think about contributing something bigger, you should
write them as soon as possible.
paul.rich...@gmail.com
> but improvements are always possible. If you find an error, fill a bug
> report or better create a patch. But also enhancement patches are
> highly welcome.
>
> c) If you want to start programming the compiler (and have some [more
> or less basic] C knowledge): I think one can find some smaller
> projects as starting point, especially accepts-invalid and diagnostic
> bugs are usually not too difficult. Compared with the middle-end
> compiler work, programming the front end is usually not to difficult
> if one has found the way through the files. One essentially programs
> like normal; only in the later parts of the compilation process when
> the structure for the middle end is generated, it gets a bit more
> complicated.
>
> d) If you are really eager or you find a student who is, one can
> easily find bigger projects, which might also be funded by e.g. Google
> summer of code. (We had two students this year.) Though starting with
> (c) makes sense.
>
> Tobias
>
> PS: Note that for bigger patches, the Free Software Foundation (FSF)
> Since paper-based letters are sent around, this might take a while.
> Thus if you think about contributing something bigger, you should
> write them as soon as possible.
Tobias,
You beat me to it! I can only repeat what you said about bugs -
please report them on Bugzilla and try to provide us with well reduced
test cases.
Paul
steven....@gmail.com
> developing a compiler seems a rather daunting task and if you
> can tell about the less daunting aspects and tasks you may get more
> people involved.
Well, daunting, daunting... Compiler construction as a (black) art is
overrated ;-)
You have to realize that not a single one of the gfortran developers
(current and past, including g95) have a computer science background.
At least, not as far as I know.
All gfortran developers are physicists, engineers, mathematicians,
etc., in their Real Life, just like most people that follow this
newsgroup. These developers started as Fortran users, with no more
knowledge of compiler construction than most people here.
If they can learn to develop a compiler, then, certainly, you can do
it too! All it takes is a willing brain and an itch to scratch, such
as some bug that prevents you from compiling your program with
gfortran.
To illustrate this, let me give an example: One of the most productive
developers of this moment was a Google Summer of Code student with
little (if any) knowledge about gcc/gfortran internals and development
processes. He only needed a couple of months to become a quite
proficient gfortran developer.
Tobias already said the rest...
Gr.
Steven
Damian
I too was daunted, but would love to contribute if I can come up to
speed.
I have about 15,000 lines of code that (at least to my way of
thinking) is very demanding in the following senses: lots of dynamic
memory allocation, lots of use of pointers, lots of defined operators
and assignments, deeply nested derived types (probably at least five
levels deep). The problem for me (which is an absolutely great
problem to have) is that gfortran runs the code perfectly, so I can't
start by reporting any bugs. On the contrary, compiling with gfortran
helped me to discover some very hard to trace bugs in my own code --
bugs that other compilers had not uncovered.
Since I can't report any new bugs, I'm glad to volunteer to work on
the things that excite me the most. I would be very excited to see
the following implemented and will contribute if someone can give me
specific guidance on where to start with these:
1. allocatable scalars
2. final procedures
3. polymorphic variables
4. type guard statements
These are the most important things I need from gfortran to get it to
compile a new code I'm working on. Of the compilers I've tried, it
currently only compiles with IBM XL Fortran.
Damian
Steven G. Kargl
Damian <dam...@rouson.net> writes:
>
> Since I can't report any new bugs, I'm glad to volunteer to work on
> the things that excite me the most. I would be very excited to see
> the following implemented and will contribute if someone can give me
> specific guidance on where to start with these:
> 1. allocatable scalars
> 2. final procedures
One of those Google SoC students mentioned elsewhere in this
already undertook final procedures. The patch will appear in 4.5.
> 3. polymorphic variables
> 4. type guard statements
> These are the most important things I need from gfortran to get it to
> compile a new code I'm working on. Of the compilers I've tried, it
> currently only compiles with IBM XL Fortran.
If you (and Arjen) want to ease into contributing to gfortran,
the easiest approach is contributions to the gfortran manual.
Read the current manual and fix grammar and spelling issues,
or expand the explanation of a feature. There's a bug report
to check that intrinsic procedures use the Standard's name
convention for formal arguments in error messages. This entails
reading the standard and the functions add_function and
add_subroutine in intrinsics.c, and fixing any discrepancies.
Having spent some time searching for tutorials on C binding,
adding a tutorial section to the manual may be an acceptable
contribution.
There's also a gfortran internals manual that Daniel Kraft started.
Read the source code, ask questions on fortran@gcc, and then
document some internal data structure. This will lead to contributing
patches to fix actual bugs.
As a semi-retired gfortran hacker, I can assure any contribution
would be welcomed.
--
steve
Arjen Markus
Well, I have always found that finding a bug report that is
about the same bug is tough, so a message to the mailing list
seems handier :).
> Note 2: It makes sense to use the latest developer release (currently
> 4.4, which is in the bug fixing stage (Stage 3) or the latest released
> version (currently 4.3.x). Regressions and important bugs (with fixed
> by simple patches) are fixed in 4.3.x and in 4.4, all other bugs will
> only be fixed in 4.4. Version 4.2 or older are effectively not
> maintained.
>
> Especially if you have access to a non-default system, testing there
> (and debugging failures) is especially appreciated as most of the
> developers are only using x86 and x86-64 Linux systems, though we have
> some regular MacOS PowerPC and Windows users and the test suite is run
> on all kind of systems. (However, we lack developers with Windows
> expertise, which is an important platform for gfortran in terms of
> usage and a bit neglected.)
>
I could bring in some experience with Windows (Cygwin, MinGW, ordinary
Windows). But I will not give any guarantee about the amount of time
(I am already involved in a number of (open source) projects and while
I am in principle interested in helping out, my attention is divided
among a lot of things already - which includes real life things ;)).
> b) The documentation (http://gcc.gnu.org/onlinedocs/gfortran/orhttp://gcc.gnu.org/onlinedocs/gfortran.pdf) is in a quite good shape,
> but improvements are always possible. If you find an error, fill a bug
> report or better create a patch. But also enhancement patches are
> highly welcome.
Now that is something I definitely can do :).
Regards,
Arjen
Arjen Markus
>
> You have to realize that not a single one of the gfortran developers
> (current and past, including g95) have a computer science background.
> At least, not as far as I know.
>
> All gfortran developers are physicists, engineers, mathematicians,
> etc., in their Real Life, just like most people that follow this
> newsgroup. These developers started as Fortran users, with no more
> knowledge of compiler construction than most people here.
>
I definitely qualify as such: I am a physicist by training and
even though day job concerns the development and maintaince of
programs in a number of languages, physics and engineering (most
notably the numerical modelling of the phenomena) remain my
prime interest.
Regards,
Arjen
tho...@ifa.hawaii.edu
> development is as follows:
I'm interested in seeing gfortran ported to another operating
system. I'm assuming that gfortran itself is written in C or
some variant of C, which means a prerequisite is having a C
compiler for that operating system, but as far as I know, the
available version of the gnu C compiler is too old. Perhaps
someone can list the steps necessary to port gfortran to
another operating system.
Phillip Helbig---remove CLOTHES to reply
<06fe625c-6212-4723...@s9g2000prg.googlegroups.com>,
"tho...@antispam.ham" <tho...@ifa.hawaii.edu> writes:
> > I think the typical way one gets deeply involved with gfortran
> > development is as follows:
>
> I'm interested in seeing gfortran ported to another operating
> system. I'm assuming that gfortran itself is written in C or
> some variant of C, which means a prerequisite is having a C
> compiler for that operating system, but as far as I know, the
> available version of the gnu C compiler is too old. Perhaps
> someone can list the steps necessary to port gfortran to
> another operating system.
Shouldn't porting it be trivial? That is, just compile and go? Or is
not everything implemented in the source code of the compiler, but
instead makes use of system calls etc?
Tobias Burnus
wrote:
If I understand it correctly, you have a system on which an older
"gcc" works, but it is too old to compile the current GCC. Assuming
that GCC is still supported on that platform, you should try to find
the newest GCC which still compiles with your old GCC (or any other C
compiler) and then use the newer GCC to compile GCC 4.4. (Another
possibility is to build an cross-compiler.)
The typical build of GCC is a three-stage process: Stage 1 uses the
installed compiler (e.g. the old GCC or a vendor compiler) to compile
a Stage1 C compiler. This compiler is then used to compile the real
GCC compiler in stage2 which is then used in stage3 to compile itself
again (including a check that stage2 and stage3 produce the same
code). Thus you only need a compiler which can create the Stage1 C
compiler.
Assuming the C part of GCC 4.4 works on the system of interest: The
front end (i.e. the actual compiler) should compile and work
flawlessly. The challenge is then the library ("libgfortran"):
Depending on the system, one needs to create stubs or system specific
functions. (By the way, the library is partially written in C [most
parts] and partially written in Fortran.) Especially on embedded
systems libgfortran might not compile or needs some special stubs.
For completeness: If your system ("target") is not supported by GCC,
you need to spend more time to get GCC working on the system,
especially if the processor is not supported since you need then to
change the part of GCC which generates the assembler. (And you need an
assembler/linker.) [If your system was supported but no longer is
supported, one could start with the old, now removed files; but unless
your system is really old I somehow doubt that your system is already
deprecated and no longer supported.]
By the way: Which processor / operating system do you have in mind?
Tobias
Carlie J. Coats
Over the last decade and a half I have developed an 80,000 line
environmental modeling utility library. All of it, including the
Makefile system, work cleanly on AIX/XLF (with choice of underscoring
convention), IRIX (5 and 6, "f77" or "f90"), Linux Alpha/DEC "fort",
Linux IA64 (Intel, gcc/g77, gcc/g95), Linux x86 (gcc/g77, gcc/g95,
Intel, PathScale, PGI (choice of underscoring), Sun StudioExpress,
Absoft (choice of underscoring), OSF1/fort, SunOS (4 or 5, f77 or f90),
Cray UNICOS f77 and f90, HP-UX (f77 and F90).
The Makefile system does *NOT* work with "gfortran" -- I've tried
several versions, the most recent being from the Mandriva RPM
gcc-gfortran-4.2.3-6mnb1. For a seemingly random set of the source
files, the make-log seems to indicate success, but the object file
is nowhere to be found, e.g.
...
cd /home/coats/Work/Linux2_x86_64gfort; gfortran -c -DIOAPICPL=1
-DAUTO_ARRAYS=1 -DF90=1 -DFLDMN=1 -DFSTR_L=int -DIOAPI_NO_STDOUT=1
-DAVOID_FLUSH=1 -O3 -ffast-math -funroll-loops -m64 -Wall -Wsurprising
-openmp -I/home/coats/Work/ioapi /home/coats/Work/ioapi/bilin.f
Warning: Nonconforming tab character in column 1 of line 22
...
ar: bilin.o: No such file or directory
...
AND:
ls /home/coats/Work/Linux2_x86_64gfort/bilin*
/bin/ls: No match.
Claiming success when the actual result is failure is *CRAP*. IBM had
a similar issue with "xlf77" fifteen years ago, and they *fixed*it*.
FWIW -- Carlie Coats
Arjen Markus
I tried to reproduce the message "Warning: nonconforming tab ..."
but even though the small test program contains one or two tabs
per line, and I specify all manner of options, I do not get that.
Could you post that particular file? I am sure the Gfortran people
are interested in that.
Regards,
Arjen
Damian
wrote:
> In article <30eb25a2-914c-4d0d-8635-618d9b000...@w24g2000prd.googlegroups.com>,
I'm glad you mentioned the C bindings tutorial. That's a great place
for me to start because C bindings play an extensive and critical role
in one of my projects and I just got a question about them from a new
user last night.
Damian
Carlie J. Coats
It's not the "nonconforming tab" issue that has me really griped -- it's
the *claim* of success in the middle of a "make" when in fact there was
a *silent* failure -- for a seemingly random subset of the source codes.
Note that it seems to work to compile codes directly from the source
directory rather than to compile codes from the object-directory by
using absolute paths to the source; the latter *fails*silently* for
about half the codes. This kind of error tells me the authors are
not serious about active work in a multi-compiler-configuration
environment (e.g., I want to keep profile- or debug-enabled executables
separate from optimized/production ones without having to do a complete
rebuild from scratch every time I turn around).
(And for that matter, "khexedit" says the "nonconforming tab" claim is
bogus! The relevant context is line-feed capital-C horizontal-tab in
fixed-form source, so that line 22 is a comment-line and "gfortran"
should not even be looking at its contents.)
If you want the whole thing:
http://www.baronams.com/products/ioapi/AVAIL.html#v30
-- Carlie
Arjen Markus
>
> If you want the whole thing:
>
> http://www.baronams.com/products/ioapi/AVAIL.html#v30
>
>
> - Tekst uit oorspronkelijk bericht weergeven -
I got it, I compiled the file bilin.f - no problem. Then
I compiled it with the option -openmp that I saw in your
compile statement ... and got the file "penmp" instead
of bilin.o !
I do not know if gfortran supports OpenMP, but at least the
flag -openmp seems to be interpreted as -o "penmp", setting
the output file.
Regards,
Arjen
Paul van Delst
Wow, good catch.
However, judging from the liberal sprinkling of "*this*" and "THAT!" in the original post,
I doubt the attitude towards gfortran is going to change too much.
FWIW, gfortran is now my main development compiler for the radiative transfer model we
work on here at JCSDA/NCEP. All Fortran95 with structures and pointers a-go-go (carefully
designed usage, of course :o) compiles and runs no worries. I have many more issues with
commercial compilers (of which I use 3 on my linux box).
cheers,
paulv
JayBee
Gfortran supports OpenMP, but the flag to enable it is -fopenmp. And
like just about every other unix compiler, "-o something" means where to
put the output file.
But clearly this is all due to the incompetence of the gfortran
developers. *rolleyes*
--
JayBee
Arjen Markus
Ah, a more recent version uses -fopenmp to enable OpenMP
(currently that version is not the default on my system)
Regards,
Arjen
Steven G. Kargl
"Carlie J. Coats" <car...@jyarborough.com> writes:
>>>
>>> The Makefile system does *NOT* work with "gfortran" -- I've tried
Actually the Makefile system does not work at all with either
FreeBSD's make or GNU make.
REMOVE:kargl[30] make
"Makefile", line 234: warning: duplicate script for target "/SOMEWHERE/" ignored
mkdir /env/proj/coats/ioapi_3/
mkdir: /env/proj/coats: No such file or directory
*** Error code 1
Stop in /usr/home/kargl/tmp/iop.
REMOVE:kargl[31] gmake
Makefile:234: warning: overriding commands for target `/SOMEWHERE'
Makefile:231: warning: ignoring old commands for target `/SOMEWHERE'
mkdir /env/proj/coats/ioapi_3/
mkdir: /env/proj/coats: No such file or directory
gmake: *** [/env/proj/coats/ioapi_3] Error 1
Of course, the complete lack of installation instruction in the
tarball might be considered a bug.
>>> several versions, the most recent being from the Mandriva RPM
>>> gcc-gfortran-4.2.3-6mnb1. For a seemingly random set of the source
>>> files, the make-log seems to indicate success, but the object file
>>> is nowhere to be found, e.g.
>>>
>>> ...
>>> cd /home/coats/Work/Linux2_x86_64gfort; gfortran -c -DIOAPICPL=1
>>> -DAUTO_ARRAYS=1 -DF90=1 -DFLDMN=1 -DFSTR_L=int -DIOAPI_NO_STDOUT=1
>>> -DAVOID_FLUSH=1 -O3 -ffast-math -funroll-loops -m64 -Wall -Wsurprising
>>> -openmp -I/home/coats/Work/ioapi /home/coats/Work/ioapi/bilin.f
>>> Warning: Nonconforming tab character in column 1 of line 22
If you actually use the correct name for the options you want, you
might have better luck. Please read the GCC manual about the -o
option and the -fopenmp option.
REMOVE:kargl[59] rm bilin.o
REMOVE:kargl[60] ~/work/bin/gfortran -c -DIOAPICPL=1 -DAUTO_ARRAYS=1 -DF90=1 -DFLDMN=1 -DFSTR_L=int -DIOAPI_NO_STDOUT=1 -DAVOID_FLUSH=1 -O3 -ffast-math -funroll-loops -Wall -Wsurprising -fopenmp bilin.f
Warning: Nonconforming tab character in column 2 of line 22
REMOVE:kargl[61] ls bilin*
bilin.f bilin.o
--
steve
Steven G. Kargl
ka...@REMOVE.apl.washington.edu (Steven G. Kargl) writes:
>>>> ...
>>>> cd /home/coats/Work/Linux2_x86_64gfort; gfortran -c -DIOAPICPL=1
>>>> -DAUTO_ARRAYS=1 -DF90=1 -DFLDMN=1 -DFSTR_L=int -DIOAPI_NO_STDOUT=1
>>>> -DAVOID_FLUSH=1 -O3 -ffast-math -funroll-loops -m64 -Wall -Wsurprising
>>>> -openmp -I/home/coats/Work/ioapi /home/coats/Work/ioapi/bilin.f
>>>> Warning: Nonconforming tab character in column 1 of line 22
>
> If you actually use the correct name for the options you want, you
> might have better luck. Please read the GCC manual about the -o
> option and the -fopenmp option.
>
> REMOVE:kargl[59] rm bilin.o
> REMOVE:kargl[60] ~/work/bin/gfortran -c -DIOAPICPL=1 -DAUTO_ARRAYS=1 -DF90=1 -DFLDMN=1 -DFSTR_L=int -DIOAPI_NO_STDOUT=1 -DAVOID_FLUSH=1 -O3 -ffast-math -funroll-loops -Wall -Wsurprising -fopenmp bilin.f
> Warning: Nonconforming tab character in column 2 of line 22
> REMOVE:kargl[61] ls bilin*
> bilin.f bilin.o
>
I forgot to mention that if you want gfortran to use the preprocessor
with all those -D options, then you need to use "-x f95-cpp-input"
or rename your file to bilin.F.
--
steve
Carlie J. Coats
Quite clearly, you did not read the page you downloaded it from, nor
the header-comment of the Makefile itself. And also quite clearly
the "gcc" language manual specifies a space between the "-o" and
the output-file name.
Nor does this explain why the very same compile command-line
options work perfectly-well with just a "<basename>.f" but do
NOT work for SOME files when invoked from a different directory
and an absolute path name for the source file.
-- Carlie
#.........................................................................
# VERSION "@(#)$Header$"
# EDSS/Models-3 I/O API Version 3.
#.........................................................................
# COPYRIGHT
# (C) 1992-2002 MCNC and Carlie J. Coats, Jr., and
# (C) 2003-2004 by Baron Advanced Meteorological Systems.
# Distributed under the GNU Lesser PUBLIC LICENSE version 2.1
# See file "LGPL.txt" for conditions of use.
#.........................................................................
# Environment Variables:
# BIN machine/OS/compiler/mode type. Shows up as suffix
# for "Makeinclude.${BIN}" to determine compilation
# flags, and in ${OBJDIR} and $(INSTALL) to determine
# binary directories
# INSTALL installation-directory root, used for "make install":
# "libioapi.a" and the tool executables will be installed
# in $(INSTDIR) = $(INSTALL)/${BIN}
#.........................................................................
# Directories:
# BASEDIR serves as a root directory for the I/O API library
# source, M3Tools source, HTML documentation, and
# (machine-specific) object/library/executable
# directories.
# SRCDIR is where the I/O API source "lives"
# OBJDIR is where the ".o" and "libioapi.a" files will be built.
# Note that its default depends upon the machine/compiler
# architecture type, specified by environment variable BIN
# INSTDIR = $(INSTALL)/${BIN} is where the "libioapi.a" files will be
# copied--must be a user-supplied environment variable
# FIXDIR is the directory in which to build extended-source-line
# fixed-source-form INCLUDE files (these files are so
# coded as to work correctly with both f90 free-form and
# standard (f77 and f90) fixed source forms.)
#.........................................................................
# Special Make-targets
# all: OBJDIR and libioapi.a
# clean: remove .o's and libioapi.a from OBJDIR
# install: copy "libioapi.a" (and "m3tools" executables) to
$(INSTDIR)
# gtar: GZipped tar-file of the source
# fixed_src: FIXDIR and extended-fixed-source INCLUDE-files
#.........................................................................
# Library Versions:
# Environment variable "BIN" specifies library version up to
# link- and compile-flag compatibility. Dependecies upon machine,
# OS, and compiler are found in file "Makeinclude.${BIN}.
# In particular, pay attention to the notes for various versions
# that may be built for Linux x86 with the Portland Group
# compilers: see comments in Makeinclude.Linux2_x86pg
#
# The following options are NOT library- nor object-compatible;
# versions with distinct combinations of these options should be
# built in *distinct* ${OBJDIR}s:
#
# Defining IOAPICPL turns on "coupling mode."
#
# Defining IOAPI_NO_STDOUT suppresses WRITEs to the screen in
# routines INIT3(), M3MSG2(), M3MESG(), and M3ABORT().
#
# Defining IO_360 creates the 360-day "global climate" version
# of the library.
#
# DEFINEFLAGS = $(ARCHFLAGS) $(PARFLAGS) \
# -DIOAPICPL=1 -DIOAPI_NO_STDOUT=1 -DIO_360=1
#
######################################################################
...
Richard Maine
<hel...@astro.multiCLOTHESvax.de> wrote:
> Shouldn't porting (the compiler) it be trivial? That is, just compile and
> go? Or is not everything implemented in the source code of the compiler,
> but instead makes use of system calls etc?
Um. Compile with what? Yes, after you have a compiler, you can use it to
compile the compiler. Boostrapping cam be decidedly non-trivial. THat's
the whole point, which it looks like you missed.
Not that I've done much of that kind of thing myself, but I'd think a
common way would be to start by making use of cross compilation. That
sure beats starting from scratch. Something I have done is "boostrap" by
using other (possibly older" compilers. But that requires a pre-existing
compiler of some kind or other, and if you are posrting a new one
because of shortcommings in the existing ones, it might be non-trivial
to get the new one to compile with the old one.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Steven G. Kargl
"Carlie J. Coats" <car...@jyarborough.com> writes:
>
> Quite clearly, you did not read the page you downloaded it from,
That is correct. I was expecting installation instruction to
be contained with the package. The missing instructions is
clearly a bug.
> nor the header-comment of the Makefile itself.
Actually, I did scan the Makefile. There are no instructions
to set the various variables. There are only definitions.
The default settings are anything but user friendly.
> And also quite clearly
> the "gcc" language manual specifies a space between the "-o" and
> the output-file name.
The manual also doesn't specify that the space is required. The
manual is written for clarity. It is also apparent you've never
used getopt(3), which states
The option string optstring may contain the following elements: individ-
ual characters, and characters followed by a colon to indicate an option
argument is to follow. For example, an option string "x" recognizes an
option ``-x'', and an option string "x:" recognizes an option and argu-
ment ``-x argument''. It does not matter to getopt() if a following
argument has leading white space.
> Nor does this explain why the very same compile command-line
> options work perfectly-well with just a "<basename>.f" but do
> NOT work for SOME files when invoked from a different directory
> and an absolute path name for the source file.
You need to post an exmaple because your Makefile system doesn't
work even when the environmental variables are set.
Finally, I'll note that the fortran at gcc.gnu.org address isn't
too difficult to find. In the 6 years, I've been subscripted to
the list, I cannot recall a single post from you about your
problems with gfortran. gfortran developers can't fix if your
refuse to communicate with them.
--
steve
Steven G. Kargl
"Carlie J. Coats" <car...@jyarborough.com> writes:
>
> Quite clearly, you did not read the page you downloaded it from, nor
> the header-comment of the Makefile itself. And also quite clearly
> the "gcc" language manual specifies a space between the "-o" and
> the output-file name.
Even if one sets the variables and if one adds -p to all
of your mkdir commands in Makefile to fix your miss use of
mkdir, one gets
.REMOVE:kargl[188] gmake
Makefile:234: warning: overriding commands for target `/usr/home/kargl/tmp/freebsd'
Makefile:231: warning: ignoring old commands for target `/usr/home/kargl/tmp/freebsd'
(cd /usr/home/kargl/tmp/iop/ioapi ; make fixed_src)
"Makefile", line 84: Could not find /usr/home/kargl/apps/ioapi/Makeinclude.freebsd
make: fatal errors encountered -- cannot continue
There appears to be a BASEDIR=$(HOME)/apps in ioapi/Makefile.
Note exactly a good assumption.
--
steve
fj
Amusing : I did exactly the same mistake few month ago when testing
OpenMP : -openmp with ifort, -xopenmp with SunF95 and -fopenmp with
gfortran. When preparing installation procedures for several compilers
and architectures, it is easy to fall down into the trap.
And I needed a quit long period to understand why I got an executable
file with the name "penmp" :-)
Gary Scott
i hate this switch syntax...at a minimum it should require a space,
perhaps a colon for human readability.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Tobias Burnus
wrote:
> I forgot to mention that if you want gfortran to use the preprocessor
> with all those -D options, then you need to use "-x f95-cpp-input"
> or rename your file to bilin.F.
In GCC/gfortran 4.4 you can also use -cpp to run the source files
through the C preprocessor.
See: http://gcc.gnu.org/gcc-4.4/changes.html
and http://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-Options.html
Tobias
Ron Ford
> Arjen Markus wrote:
>> On 19 sep, 15:27, "Carlie J. Coats" <car...@jyarborough.com> wrote:
>>> If you want the whole thing:
>>>
>>> http://www.baronams.com/products/ioapi/AVAIL.html#v30
>>>
>>> -- Carlie- Tekst uit oorspronkelijk bericht niet weergeven -
>>>
>>> - Tekst uit oorspronkelijk bericht weergeven -
>>
>> I got it, I compiled the file bilin.f - no problem. Then
>> I compiled it with the option -openmp that I saw in your
>> compile statement ... and got the file "penmp" instead
>> of bilin.o !
>>
>> I do not know if gfortran supports OpenMP, but at least the
>> flag -openmp seems to be interpreted as -o "penmp", setting
>> the output file.
>
> Wow, good catch.
<snip>
Really? I used the appropriate openmp flag for gfortran for the first time
a couple weeks back and Tobias Burns advised me so:
F:\gfortran\source>gfortran -o thread -fopenmp ff55.f90
Seems unambiguous enough. If there's anything I miss when I use gfortran
it's an IDE and visual debugger. The mingw people have one now for c/c++;
maybe in a year it will be adapted for fortran.
--
Historian: an unsuccessful novelist.
H. L. Mencken
Terence
1) having a degree in Computer Technology of any kind, might help with
designing a compiler, but is not essential. I don't see a lack of such
in the gfortran team to be worthy of complaint.
Being qualified to think is foremost.
To be a long-time user of Fortran and C compilers certainly is
important. Having time to write a good, clear installalion manual for
the compiler, is much, much, more important. I mysel DO have an MSc in
Comp. Tech and other degrees in Maths and Physics, etc, (and
commercially write compilers using Fortran) but I occasionally get
scorn heaped on my Fortran advice for being too conservative. I
wouldn't think of designing and writing a Fortran compiler; I bless
those who do for the general good.
2) I worry about the mentioned stages of "compiling compilers". Why
not specify some recognised c-compiler as a base-point and offer a
start from there; those who don't have such a commercial or otherwise
starting point can download a required first-stage compiler.. But
again, clear instructions are vital.
3) It seems obvious there is a beginning divergence in option coding.
Perhaps a nested structure is needed for the user/installer to first
define a target environment, and within that, the particular form of
the option codes to be used are now pre-defined, and taken from a
replaceable table.
4) There is always my sore point. Fortran needs to interact with the
operating system environment, especially screen, keyboard and mouse,
and possibly USB and other user ports to external devices. This should
be tackled by defining an interace; then the public can help in
provided run-time operating-system dependant device access libraries.
I don't see that the Fortran committees have ever touched this area.
steven....@gmail.com
You know what is really crap? People blaming others for their own
stupidity.
> cd /home/coats/Work/Linux2_x86_64gfort; gfortran -c -DIOAPICPL=1
> -DAUTO_ARRAYS=1 -DF90=1 -DFLDMN=1 -DFSTR_L=int -DIOAPI_NO_STDOUT=1
> -DAVOID_FLUSH=1 -O3 -ffast-math -funroll-loops -m64 -Wall -Wsurprising
> -openmp -I/home/coats/Work/ioapi /home/coats/Work/ioapi/bilin.f
^
In GCC (and therefore also in gfortran), -oxxxx means "call the object
file "xxxx.o".
You want -fopenmp.
Before you blame the tool, read the fine manual.
Gr.
Steven
steven....@gmail.com
Yes, you're right and you're not the first to point this out.
But legacy, oh legacy... We Fortran-ers know all about it, no? :-)
Gr.
Steven
Phillip Helbig---remove CLOTHES to reply
nos...@see.signature (Richard Maine) writes:
> Phillip Helbig---remove CLOTHES to reply
> <hel...@astro.multiCLOTHESvax.de> wrote:
>
> > Shouldn't porting (the compiler) it be trivial? That is, just compile and
> > go? Or is not everything implemented in the source code of the compiler,
> > but instead makes use of system calls etc?
>
> Um. Compile with what? Yes, after you have a compiler, you can use it to
> compile the compiler. Boostrapping cam be decidedly non-trivial. THat's
> the whole point, which it looks like you missed.
I was thinking a) it is written in C and b) I have a normal C compiler.
> Not that I've done much of that kind of thing myself, but I'd think a
> common way would be to start by making use of cross compilation.
Apropos.... Isn't the possibility of cross-compilation the reason some
things are not allowed by the Fortran standard, while there is no
"obvious" reason they should be disallowed?
Richard Maine
<hel...@astro.multiCLOTHESvax.de> wrote:
> In article <1inifpp.1j92xdij344rcN%nos...@see.signature>,
> nos...@see.signature (Richard Maine) writes:
>
> > Phillip Helbig---remove CLOTHES to reply
> > <hel...@astro.multiCLOTHESvax.de> wrote:
> >
> > > Shouldn't porting (the compiler) it be trivial? That is, just compile and
> > > go? Or is not everything implemented in the source code of the compiler,
> > > but instead makes use of system calls etc?
> >
> > Um. Compile with what? Yes, after you have a compiler, you can use it to
> > compile the compiler. Boostrapping cam be decidedly non-trivial. THat's
> > the whole point, which it looks like you missed.
>
> I was thinking a) it is written in C and b) I have a normal C compiler.
Sometimes. Not always. Apparently you overlooked the
>>>> as far as I know, the
>>>> available version of the gnu C compiler is too old
Which was in the para that you replied to with the comment that porting
should be trivial.
> Apropos.... Isn't the possibility of cross-compilation the reason some
> things are not allowed by the Fortran standard, while there is no
> "obvious" reason they should be disallowed?
Yes, that reason has been cited in the past. However, it doesn't seem to
be considered much of a problem any more, so some of those restrictions
have been lifted. Cross compilation is still needed on occasion, but
cross compilers today generally have more capability. For example, there
was concern in the past about cross compilers having to do things like
implement all the intrinsics twice - once for the target environment and
once for the compilation environment. That concern contributed towards
keeping the list of intrinsics allowed in initialization expressions
down. Today, I think the assumption is that if such duplication is
needed, it can be done. Resources in the compilation environment are not
likely to be as shot as they previously might have been. In fact,
compilation environments for cross compilers are typically fairly "rich"
environments and often include things such as software emulators for the
target.
Gary Scott
time I ask the main cross-compiler vendors (Green Hills, DDC-I), they
just laugh at me.
Richard Maine
> Does someone actually produce a Fortran cross-compiler today? Every
> time I ask the main cross-compiler vendors (Green Hills, DDC-I), they
> just laugh at me.
Yes. I don't personally do that kind of stuff, so I don't keep up with
it, but Fortran cross compilers are bound to exist. Let's see... doing
the most obvious thing (googling "fortran cross compiler") pretty
quickly comes up with at least one good hit near the top. I yhink I
recall discussions of that one here also. From some Intel compiler docs,
"Intel® Fortran Compiler for Itanium(TM)-based Applications, or cross
compiler, runs on IA-32 systems but produces Itanium(TM)-based
applications." If you are going to complain that from one Intel
architecture to another isn't "cross enough" for you, then you are
getting into much more specific questions than whether such things as
Fortran cross compilers exist at all.
I also believe that the Gnu compilers can be built in cross-compiler
configurations, though I haven't done that myself and could be wrong.
And you mentioned Green Hills. I thought I recalled they did Fortran
cross compilers. Hmm. Quickly skimming their web site certainly finds
allusions to cross compilers and to Fortran compilers. Hmm, but I'm not
entirely sure I see the two explicitly linked. Well, not worth spending
a lot of my time on a casual request; you've obviously investigated more
thoroughtly that I have.
James Van Buskirk
news:pG9Bk.735$D32...@flpi146.ffdc.sbc.com...
> Does someone actually produce a Fortran cross-compiler today? Every time
> I ask the main cross-compiler vendors (Green Hills, DDC-I), they just
> laugh at me.
The Intel compilers for 64-bit Windows at least used to be cross-
compilers in that they ran under 32-bit mode, making it in principle
possible to overrun compiler resources for a program that would not
exceed runtime resources.
There are gfortran builds for 64-bit Windows that run on 32-bit
Windows, Cygwin, or even LINUX. I think they are all built on
LINUX because the build environment assumes some kind of UNIX
command shell, so the versions that don't run under LINUX or 64-bit
Windows are triple crosses.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Gary Scott
> Gary Scott <garyl...@sbcglobal.net> wrote:
>
>
>>Does someone actually produce a Fortran cross-compiler today? Every
>>time I ask the main cross-compiler vendors (Green Hills, DDC-I), they
>>just laugh at me.
>
>
> Yes. I don't personally do that kind of stuff, so I don't keep up with
> it, but Fortran cross compilers are bound to exist. Let's see... doing
> the most obvious thing (googling "fortran cross compiler") pretty
> quickly comes up with at least one good hit near the top. I yhink I
> recall discussions of that one here also. From some Intel compiler docs,
> "Intel® Fortran Compiler for Itanium(TM)-based Applications, or cross
> compiler, runs on IA-32 systems but produces Itanium(TM)-based
> applications." If you are going to complain that from one Intel
> architecture to another isn't "cross enough" for you, then you are
> getting into much more specific questions than whether such things as
> Fortran cross compilers exist at all.
>
> I also believe that the Gnu compilers can be built in cross-compiler
> configurations, though I haven't done that myself and could be wrong.
>
> And you mentioned Green Hills. I thought I recalled they did Fortran
> cross compilers. Hmm. Quickly skimming their web site certainly finds
> allusions to cross compilers and to Fortran compilers. Hmm, but I'm not
> entirely sure I see the two explicitly linked. Well, not worth spending
> a lot of my time on a casual request; you've obviously investigated more
> thoroughtly that I have.
>
If you dig through both GH and DDC-I web pages, you can dig up
references to Fortran 77. They appear to be obsolete/unmaintained as
far as I can tell. I'm sure if someone with enough $$$ wanted one,
they'd resurrect it (at least F77), but they appear to have no interest
in updating to a modern dialect, and it would probably take a LOT more
$$$ to convince them.
Yeah, I'm ok with 32 bit compilers producing 64 bit code being
considered cross compilers (can't really argue with it), but was
thinking more of developing PPC (1750, Z80, 68000, MIPS...) code with an
X86 development platform/environment (i.e. completely different
architecture).
I've been getting lots of emails from DDC-I for the last year about
"real-time" Java for embedded (cross-compilation) development. They're
pushing it as a replacement for Ada and C development. I forwarded it
to some of the CS types that do that for a living and their response was
less than accepting. They seem to be pushing forward with it though.
Seems like "real-time" F2k should be just as enticing.
glen herrmannsfeldt
(snip)
> The Intel compilers for 64-bit Windows at least used to be cross-
> compilers in that they ran under 32-bit mode, making it in principle
> possible to overrun compiler resources for a program that would not
> exceed runtime resources.
One would hope that the code for most programs would fit
in 2GB even
integer x(10000000000)
x=1
write(*,*) x(987654)
end
will compile in 32bit g95, but won't run.
integer x(1000000000)
data x/1000000000*1/
write(*,*) x(987654)
end
the compiler runs for over seven minutes before it dies with
an internal compiler error. (g95 0.91)
Someone last year had a very complicated DATA statement
that would run out of compiler resources much earlier.
> There are gfortran builds for 64-bit Windows that run on 32-bit
> Windows, Cygwin, or even LINUX. I think they are all built on
> LINUX because the build environment assumes some kind of UNIX
> command shell, so the versions that don't run under LINUX or 64-bit
> Windows are triple crosses.
There are versions of unix-like command shells, that
run on cygwin and on Win-32.
-- glen
glen herrmannsfeldt
(snip)
> For example, there
> was concern in the past about cross compilers having to do things like
> implement all the intrinsics twice - once for the target environment and
> once for the compilation environment. That concern contributed towards
> keeping the list of intrinsics allowed in initialization expressions
> down. Today, I think the assumption is that if such duplication is
> needed, it can be done.
It does get interesting when the source and target systems have
different floating point formats. Also, even on the same system
some do constant arithmetic in software. When the pentium FDIV
bug came out, some test programs failed to detect it, doing the
constant division expression as software emulation.
I could imagine more differences in the results of compile
time and run time intrinsic functions. Another reason not
to do equality testing of floating point values.
-- glen
Richard Maine
> I could imagine more differences in the results of compile
> time and run time intrinsic functions. Another reason not
> to do equality testing of floating point values.
Yes, and I think the current thinking is more along exactly those lines
- that this is a case of the reasons to avoid dependence on exact
equality of floating point things in general, as opposed to a reason to
limit the language just because such inequality might happen in a cross
compilation.
Ron Ford
Terence,
Do you favor us from the point-of-view from the other seppoes?
To wonder why I ask gets to the Condie Rice thing. I'm the the guy who
interrecepts the usual " mto mbi ee etto ckazal. "
I seem to have a datatype that doesn't cpunt Cleveland.
--
A prohibitionist is the sort of man one couldn't care to drink with, even
if he drank.
H. L. Mencken
steven....@gmail.com
> Does someone actually produce a Fortran cross-compiler today? Every
> time I ask the main cross-compiler vendors (Green Hills, DDC-I), they
> just laugh at me.
You can build gfortran as a cross-compiler. GCC is designed as a
cross-compiler framework. gfortran is part of GCC, so if you build
GCC (with fortran enabled) as a cross-compiler, you will get a cross-
compiling gfortran.
Cross-compiling with gfortran is even relatively well tested. For
many targets that GCC supports, e.g. embedded systems or the Cell SPU,
you have to use a cross-compiler because the target cannot host a
compiler. GCC developers regularly include gfortran when they build/
test a cross-compiler for their favorite embedded target. For the
Cell SPU, Debian has a gfortran cross compiler package IIRC.
In theory, you can even build GCC as a "Canadian cross compiler" but I
don't know how well-tested this is.
Gr.
Steven
Steve Lionel
>> Does someone actually produce a Fortran cross-compiler today? Every time
>> I ask the main cross-compiler vendors (Green Hills, DDC-I), they just
>> laugh at me.
>
> The Intel compilers for 64-bit Windows at least used to be cross-
> compilers in that they ran under 32-bit mode, making it in principle
> possible to overrun compiler resources for a program that would not
> exceed runtime resources.
True, but it also allowed you to develop 64-bit applications on a 32-bit
system. In ifort version 11, a native 64-bit compiler is installed for
use on 64-bit systems; the cross-compiler is still there for 32-bit systems.
There are many cross-compilers on the market, especially for the
embedded space.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
Colin Paul Gloster
|--------------------------------------------------------------------------------|
|"[..] |
|If you dig through both GH and DDC-I web pages, you can dig up references to |
|Fortran 77. They appear to be obsolete/unmaintained as far as I can tell. I'm |
|sure if someone with enough $$$ wanted one, they'd resurrect it (at least F77), |
|but they appear to have no interest in updating to a modern dialect, and it |
|would probably take a LOT more $$$ to convince them. |
| |
|[..]" |
|--------------------------------------------------------------------------------|
This is the case with most languages which they supposedly support.
Beliavsky
> Al and Damian,
>
> Many thanks for the praise - every little bit helps:-)
>
> > > Over the last few years I have developed a 30,000 line Fortran-95
> > > engineering application using simultaneously several compilers (XLF,
> > > LF95, G95, and IVF). During that time I toyed with Gfortran and put
> > > up with the 2 steps forward, 1 step back of each binary build.
>
> because of the inadequacy, in the past, of our testsuite. Not having
> a take-the-standard-and-write-a-testsuite yardstick to go by, ours has
> grown as we have fixed bugs and regressions.
They do exist, for example http://www.fortran.com/f95ts.html . How
much do they cost? I would donate a few hundred dollars toward buying
one, if the Gfortran started a collection.
Tobias Burnus
> On Sep 18, 3:56 am, paul.richard.tho...@gmail.com wrote:
> > We are sharply aware of this problem. It has come about largely
> > because of the inadequacy, in the past, of our testsuite. Not having
> > a take-the-standard-and-write-a-testsuite yardstick to go by, ours has
> > grown as we have fixed bugs and regressions.
>
> much do they cost? I would donate a few hundred dollars toward buying
> one, if the Gfortran started a collection.
By now the test suites are by far not as useful as before. The above-
mentioned test suite is also available from NAG. When I once asked
there how much it costs the answer was something like 15000 pounds (I
don't recall the exact amount). However, I have privately bought the
light version of it (http://www.fortran.com/f90tsl.html) for a
discount price (still $$$); using it I found just about half a dozen
bugs.
Additionally, Dick Hendrickson has used his Shape95 Spackman &
Hendrickson Fortran test suite (also worth $$$$$) to check gfortran
and has reported 43 bugs of which 7 remain to be fixed. (Thanks!)
I would assume that with the F95 test suite of fortran.com/NAG one can
find a couple of bugs, but presumably too few that it makes sense to
spend $$$$$, especially since there is the problem how to make it
available to whom within the licensing constrains.
In any case Fortran 2003 is not covered by any test suite so far.
(Well, ignoring the private collection of the compiler vendors and the
public but implementation-tailored collection of gfortran.)
For iron out the remaining gfortran bugs, I think one has essentially
to rely on users which report bugs.
Tobias
PS: I know someone who co-developes a larger Fortran program and he
complained that Fortran compilers are buggy: With C errors are almost
certainly user errors, but for Fortran one can never rule out compiler
bugs; the program thus now contains a couple of workarounds.I have to
agree: It is not too difficult to hit a compiler error now and then -
and I have already found several bugs in NAG f95, ifort, g95,
gfortran, sunf95, ... For gfortran, one can have the hope that its
wide-spread use will help to make it harder and harder to encounter
compiler bugs; fortunately, most of the reported bugs are old bugs or
bugs in new features and not regressions, e.g. things which used to
work with older gfortran versions.
Gary Scott
You noticed that too...well I didn't want to go quite that far. But
they do have unique requirements which drive up costs and make them
timid related to "safety" and "security" certifications that don't often
apply to commercial or open source projects.
Colin Paul Gloster
|------------------------------------------------------------------------------------|
|"Colin Paul Gloster wrote: |
| |
|> On Sat, 20 Sep 2008, Gary Scott wrote: |
|> |
|> |--------------------------------------------------------------------------------||
|> |"[..] |
|> | |
|> |If you dig through both GH and DDC-I web pages, you can dig up references to |
|> | |
|> |Fortran 77. They appear to be obsolete/unmaintained as far as I can tell. |
|> I'm | |
|> |sure if someone with enough $$$ wanted one, they'd resurrect it (at least |
|> F77), | |
|> |but they appear to have no interest in updating to a modern dialect, and it |
|> | |
|> |would probably take a LOT more $$$ to convince them. |
|> | |
|> | |
|> | |
|> |[..]" |
|> | |
|> |--------------------------------------------------------------------------------||
|> |
|> This is the case with most languages which they supposedly support. |
| |
|You noticed that too...well I didn't want to go quite that far. But they do |
|have unique requirements which drive up costs and make them timid related to |
|"safety" and "security" certifications that don't often apply to commercial or |
|open source projects." |
|------------------------------------------------------------------------------------|
How can a compiler vendor (i.e. DDC-I) market an Ada 95 compiler but not
RAVENSCAR (Reliable Ada Verifiable Executive Needed for Scheduling
Critical Applications in Real-time) almost ten years after the
definition of RAVENSCAR (an Ada 2005 version of which is enshrined as
an official profile in the Ada 2005 standard) yet be described as
being timid because of requirements for safety? Other safety-critical
Ada compiler writers provide RAVENSCAR.
Java is dynamic therefore by its very nature is less suitable for a
safe system but DDC-I wants people to think that it can give them an
excellent Java implementation.
Yours sincerely,
Colin Paul Gloster
Colin Paul Gloster
|--------------------------------------------------------------------------|
|"[..] |
| |
|Tobias |
| |
|PS: I know someone who co-developes a larger Fortran program and he |
|complained that Fortran compilers are buggy: With C errors are almost |
|certainly user errors, but for Fortran one can never rule out compiler |
|bugs; the program thus now contains a couple of workarounds.I have to |
|agree: It is not too difficult to hit a compiler error now and then - |
|and I have already found several bugs in NAG f95, ifort, g95, |
|gfortran, sunf95, ... For gfortran, one can have the hope that its |
|wide-spread use will help to make it harder and harder to encounter |
|compiler bugs; fortunately, most of the reported bugs are old bugs or |
|bugs in new features and not regressions, e.g. things which used to |
|work with older gfortran versions." |
|--------------------------------------------------------------------------|
Tobias,
Thank you for contradicting Steven Bosscher's claim in
news:5b3f0a83-bc01-429b...@m36g2000hse.googlegroups.com
that people who have not studied the principles of compilers develop a
good compiler:
|----------------------------------------------------------------------|
|"On Sep 18, 4:13 pm, Arjen Markus <arjen.mar...@wldelft.nl> wrote: |
|> Perhaps you can describe in some detail how people can help out: |
|> developing a compiler seems a rather daunting task and if you |
|> can tell about the less daunting aspects and tasks you may get more |
|> people involved. |
| |
|Well, daunting, daunting... Compiler construction as a (black) art is|
|overrated ;-) |
| |
|You have to realize that not a single one of the gfortran developers |
|(current and past, including g95) have a computer science background. |
|At least, not as far as I know. |
| |
|All gfortran developers are physicists, engineers, mathematicians, |
|etc., in their Real Life, just like most people that follow this |
|newsgroup. These developers started as Fortran users, with no more |
|knowledge of compiler construction than most people here. |
| |
|If they can learn to develop a compiler, then, certainly, you can do |
|it too! All it takes is a willing brain and an itch to scratch, such |
|as some bug that prevents you from compiling your program with |
|gfortran. |
| |
|To illustrate this, let me give an example: One of the most productive|
|developers of this moment was a Google Summer of Code student with |
|little (if any) knowledge about gcc/gfortran internals and development|
|processes. He only needed a couple of months to become a quite |
|proficient gfortran developer. |
| |
|Tobias already said the rest... |
| |
|Gr. |
|Steven" |
|----------------------------------------------------------------------|
Fortran exists because of one man. His formalism of language syntax
is virtually essential for studying languages and is used even in many
general purpose textbooks (even for describing Verilog and VHDL to
undergraduates of electronic engineering) instead of merely in books
on how to write compilers, but I have never seen it in a Fortran book.
Writing compilers without reading about established techniques on how
to do so is not effective. I am aware of someone who had graduated in
computer science who has tried to write a compiler without consulting
the literature, and he did not do well.
The aforementioned hero of language formalism and Fortran said that
FORTRAN I was good for the beginning of high-level programming but
that it should not be kept as a basis for better languages. Please
read hardcopy Pages 42 and 43 (PDF Pages 18 and 19) of
http://portal.acm.org/citation.cfm?id=800025.1198345&coll=Portal&dl=GUIDE&CFID=3908514&CFTOKEN=33193345
Gary Scott
Exacry
>
> Yours sincerely,
> Colin Paul Gloster
Tobias Burnus
wrote:
> Thank you for contradicting Steven Bosscher's claim innews:5b3f0a83-bc01-429b...@m36g2000hse.googlegroups.com
> that people who have not studied the principles of compilers develop a
> good compiler
You mean that people at Intel, Pathscale, NAG, Absoft, Sun, Portland
Group, IBM etc. have not "not studied the principles of compilers
develop a good compiler"? Or how should I interpret this? I would
claim that be larger problem is the relatively smaller user base
(compared with C), which was also spread over a large number of
Fortran compilers; having new features does also not help to reduce
the number of bugs bugs. I would also claim that Fortran is complex
enough to overlook something when implementing something new.
For gfortran I see the number of Fortran 95 bugs constantly decreasing
(judging from the bug reports), but it will of cause never be bugfree
and there are enough possibilities for bugs when Fortran 2003/2008
features get implemented.
> Writing compilers without reading about established techniques on how
> to do so is not effective. I am aware of someone who had graduated in
> computer science who has tried to write a compiler without consulting
> the literature, and he did not do well.
I want to point out that there are several GCC developers which have
studied computer science and do compiler development for living; I
pretty sure that a large number of them knows compiler development
literature. That number of people knowing compiler literature inside
out might be less in gfortran than in other parts of GCC, but is also
not zero. I think your view it too much black and white, while
reality is different shades of grey.
> The aforementioned hero of language formalism and Fortran said that
> FORTRAN I was good for the beginning of high-level programming but
> that it should not be kept as a basis for better languages.
As Fortran is now around for 50 years and still moderately widely
used, contrary to some other languages, what does this proof?
Tobias
Colin Paul Gloster
I wish to point out that I was not trying to upset anyone. If I upset
you, then I am sorry.
On Wed, 24 Sep 2008, Tobias Burnus wrote:
|------------------------------------------------------------------------|
|"On Sep 24, 12:11 pm, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> |
|wrote: |
|> Thank you for contradicting Steven Bosscher's claim in |
|news:5b3f0a83-bc01-429b...@m36g2000hse.googlegroups.com |
|> that people who have not studied the principles of compilers develop a|
|> good compiler |
| |
|You mean that people at Intel, Pathscale, NAG, Absoft, Sun, Portland |
|Group, IBM etc. have not "not studied the principles of compilers |
|develop a good compiler"? Or how should I interpret this?" |
|------------------------------------------------------------------------|
I have checked again what I quoted from Steven Bosscher and I concede
that depending on exactly what he posted meant, he might not have
claimed that Gfortran contributors did not bother to read established
literature on established compilation techniques if doing so late in
life is excluded from someone's "background".
|------------------------------------------------------------------------|
|" I would |
|claim that be larger problem is the relatively smaller user base |
|(compared with C), which was also spread over a large number of |
|Fortran compilers; having new features does also not help to reduce |
|the number of bugs bugs. I would also claim that Fortran is complex |
|enough to overlook something when implementing something new." |
|------------------------------------------------------------------------|
I am not promoting any compiler as lacking bugs, but the arguments you
suggested are not valid for FORTRAN 77, which in the 1990's supposedly
was not supported as well as one had expected considering the many
years compiler writers had used. A quotation from Pages xii and xiii
of the second edition of "Numerical Recipes in FORTRAN : The Art of
Scientific Computing":
"[..]
[..] Also used were a variety
of FORTRAN compilers - too numerous (and sometimes too buggy) for individual
acknowledgment. It is a sobering fact that our standard test suite (exercising all the
routines in this book) has uncovered compiler bugs in a large majority of the compil-
ers tried. [..]
[..]"
I do not know whether an Intel; Pathscale; NAG; Absoft; or Portland
Group compiler was one of the buggy compilers mentioned in that book.
The aforementioned pioneer of compiler theory used to work for IBM and
he claimed on the pages I explicitly mntioned in the paper I cited
(which perhaps you did not read) that IBM employees disregarded his
advice on how to make good compilers.
Major criticism of C and C++ is attributed on
WWW.ACM.org/crossroads/xrds14-2/franallen.html
to another expert of compiler theory who used to work for IBM, but a
few weeks ago IBM told me that its licensing options would not permit
me to acquire one of its Ada compilers without also acquiring a C++
compiler. I do not want a C++ compiler.
People at Sun certainly have studied how to make compilers.
|------------------------------------------------------------------------|
|"For gfortran I see the number of Fortran 95 bugs constantly decreasing |
|(judging from the bug reports), but it will of cause never be bugfree |
|and there are enough possibilities for bugs when Fortran 2003/2008 |
|features get implemented." |
|------------------------------------------------------------------------|
Congratulations. Writing a grammar for any practical language is much
harder than it would first seem.
|------------------------------------------------------------------------|
|"> Writing compilers without reading about established techniques on how|
|> to do so is not effective. I am aware of someone who had graduated in |
|> computer science who has tried to write a compiler without consulting |
|> the literature, and he did not do well. |
| |
|I want to point out that there are several GCC developers which have |
|studied computer science and do compiler development for living; I |
|pretty sure that a large number of them knows compiler development |
|literature." |
|------------------------------------------------------------------------|
Yes.
|------------------------------------------------------------------------|
|" That number of people knowing compiler literature inside |
|out might be less in gfortran than in other parts of GCC, but is also |
|not zero. [..]" |
|------------------------------------------------------------------------|
I had not known that.
|------------------------------------------------------------------------|
|"> The aforementioned hero of language formalism and Fortran said that |
|> FORTRAN I was good for the beginning of high-level programming but |
|> that it should not be kept as a basis for better languages. |
| |
|As Fortran is now around for 50 years and still moderately widely |
|used, contrary to some other languages, what does this proof?" |
|------------------------------------------------------------------------|
As proofs are impossible, it does not prove anything. It is however
another case to demonstrate that inertia can result in better things
not significantly replacing inferior things. Other examples of popular
things which are inferior to alternatives are C; French; English;
German; and standard rubber bicycle tubes which can easily be
punctured.
Fortran is not "now around for 50 years". Just because you call
Fortran 2008 Fortran, does not mean that it is Fortran. It has been
claimed that a number of FORTRAN I features were not kept in FORTRAN
77. These omissions resulted in a better and different language.
Beliavsky
> Over the last few years I have developed a 30,000 line Fortran-95
> engineering application using simultaneously several compilers (XLF,
> up with the 2 steps forward, 1 step back of each binary build.
> resolved and more importantly performance is almost identical to XLF
> and IVF in most cases. Congratulations to all involved with this
> project!
I'd like to verify the progress for myself by using a recent version
of Gfortran for Windows, but at http://gcc.gnu.org/wiki/GFortranBinaries
the latest version is dated 2008-04-15 :(.
Steven G. Kargl
So, build it from source. Note, this exercise can actually
help the development if you report your results (good and bad).
--
steve
Beliavsky
wrote:
> > I'd like to verify the progress for myself by using a recent version
> > of Gfortran for Windows, but at http://gcc.gnu.org/wiki/GFortranBinaries
> > the latest version is dated 2008-04-15 :(.
>
> So, build it from source. Note, this exercise can actually
> help the development if you report your results (good and bad).
Yes, that is certainly the attitude to have if Gfortran is to get wide
usage among Windows Fortran programmers (and thus their bug reports).
There should be no Linux distributions other than Gentoo, either.
>
> --
> steve
James Van Buskirk
news:e5686817-0a02-449e...@v28g2000hsv.googlegroups.com...
> I'd like to verify the progress for myself by using a recent version
> of Gfortran for Windows, but at http://gcc.gnu.org/wiki/GFortranBinaries
> the latest version is dated 2008-04-15 :(.
Go to http://www.equation.com . If you are on x64, there are also
recent versions at http://sourceforge.net/projects/mingw-w64/ . The
one dated 9/18 is probably OK but the 9/20 build is suspect.
Previous builds that were so small were due to failure of the build
process. The advantage of the mingw-w64 site is that its builds use
up to date versions of the mingw libraries which do not necessarily
get incorporated into the equation.com builds in a timely fashion.
Maybe there are analogous builds for *32 at the main mingw site,
but I have not been able to find them.
Al Greynolds
> I'd like to verify the progress for myself by using a recent version
> the latest version is dated 2008-04-15 :(.
You can get updated-weekly Windows binary builds of Gfortran at:
http://www.equation.com/servlet/equation.cmd?call=fortran
Al
Dick Hendrickson
I saw that also. But, I downloaded it anyhow and when I try
it, it tells me it is a 2008-06-03 version. That's a little more
recent. Just goes to show the danger of putting information in the
documentation.
Dick Hendrickson
Don't just do something, stand there. It's too late to panic.
steven....@gmail.com
> On Oct 2, 5:19 pm, ka...@REMOVE.apl.washington.edu (Steven G. Kargl)
> wrote:
>
> > > I'd like to verify the progress for myself by using a recent version
> > > the latest version is dated 2008-04-15 :(.
>
> > So, build it from source. Note, this exercise can actually
> > help the development if you report your results (good and bad).
>
> Yes, that is certainly the attitude to have if Gfortran is to get wide
> usage among Windows Fortran programmers (and thus their bug reports).
> There should be no Linux distributions other than Gentoo, either.
What are you asking for, then? Right now, no-one is capable of (or
willing to) providing windows binaries. And your reaction is to blame
and taunt people for not solving *your* problem. Do you behave like
that in your day-time job, too? Instead, you could step up and help.
That'd be a much more welcome contribution (both here in this
newsgroup, and in general for gfortran) than your pointless and
baseless remark quoted above.
You react as if it is the responsibility of the gfortran community to
bring binaries to you. But it is not. At best, someone could be
willing to make those binaries available to you. And if that doesn't
happen, you should be happy you can build your own gfortran from
source. Extra bonus if you're willing to upload them on the gfortran
wiki to make your binaries available to others.
Gr.
Steven
GaryScott
:) Maybe Intel will give me the source to IVF so I can build it myself.
Steven G. Kargl
What's your point?
I'll gladly set up a Windows box and make available daily builds of
gfortran, if someone is willing to pay me as well as Intel pays
its compiler team. Barring a benevolent individual, the only options
are (1) use the version of gfortran available from the wiki or (2)
build gfortran from source to get the bleeding edge.
--
steve
glen herrmannsfeldt
(snip)
> I'll gladly set up a Windows box and make available daily builds of
> gfortran, if someone is willing to pay me as well as Intel pays
> its compiler team. Barring a benevolent individual, the only options
> are (1) use the version of gfortran available from the wiki or (2)
> build gfortran from source to get the bleeding edge.
3) Download the free VMware and a virtual disk with Linux installed.
(I recommend ScientificLinux, see www.scientificlinux.org)
Install gfortran in that virtual machine inside windows.
-- glen
GaryScott
No way am I using a crude setup like that...I want a complete plug-n-
play product with IDE, tools, compiler, and support I can actually
call and speak with.