gfortran 2007 annual report
paul.rich...@gmail.com
of known F95 bugs has gone down sharply, the diagnostic capability
has increased and new F2003/8 features added.
Hopefully, the contributors can continue to move forward with bug
fixes, conformance to Fortran 95 standard, and the implementation of
Fortran 2003/8 features. However, this needs new blood in the ranks,
particularly since Steve Kargl and Bud Davis have hung up their
maintainer hats and some of the other regulars are struggling with
competition between gfortran and daytime jobs or moves between
countries.
If you have any interest in helping out, please do not hestitate to
contact one of us or to mail the gfortran list, for help on how to
get started.
An important source of help to us is bug reporting. Best of all is
for
bugs to be posted in Bugzilla with well reduced testcases. There is a
group of regulars out there whose efforts are really appreciated. It
is
noticable that threads on comp.lang.fortran are becoming increasingly
important; particularly to resolve thorny issues of Standard
interpretation but also for picking up bugs. A favourite was "Most
elegant syntax for inverting a permutation?" which led to corrections
of problems with assignment and FORALL.
As an aside, it should be noted that the main part of this report
was written by Steve Kargl. Many thanks, Steve! Thank you for all
your contributions over the years and, should you change your mind,
we all look forward to you rejoining us.
A few highlights from the past year are:
1) Chris Rickett's ISO C Binding patch. He did ~95% of work with
Tobias Burnus, F-X Coudert and Steve Kargl throwing the odd fix
here and there.
2) Daniel Franke and Brooks Moses wrote, rewrote, and re-organized
large portions of the gfortran manual. This is a thankless task
that has resulted in a great improvement to the documentation
of gfortran.
3) Brooks and Pault finally implemented TRANSFER(), which was a
glaring omission in gfortran's conformance to the F95 standard.
4) Janus Weil was gfortran's first Google SoC student. He worked
on the Fortran 2003 PROCEDURE feature. Procedure pointers will
be implemented in 2008.
5) An important milestone only a few may notice is that the number
of bug reports against conformance to F95 is diminishing. This
has been a collective effort with all the maintainers keeping an
eye on the "bug-bashing" part of the gfortran wiki, mentioned at
the end of this report.
6) Janne Blomqvist finally got his symbol versioning patch into the
tree.
7) F-X Coudert, Thomas Koenig, Jerry DeLisle, Janne Blomqvist, and
Daniel Franke(and others) have expended a large amount of effort
on making libgfortran more robust, faster, cleaner, etc.
8) Subreference array pointers, which was the last missing F95
feature, were implemented by Paul Thomas. This feature permits
likes of "my_int_pointer => my_type(:)%int_cmp".
9) At some stage in the year, some underlying bugs were fixed that
allowed J.L.Schonfelder's ISO Varying String testsuite to run
faultlessly with Rich Townsend's version of the ISV library, which
uses allocatable components, aka TR 15581.
10) The backtrace/code-dump option was added by F-X Coudert.
11) The -finit-* options were added by Asher Langton.
12) Although the postion of gfortran in the Polyhedron performance
tables has not changed much, the diagnostic rating has creapt up
from 34% to 42%.
There were 497 commits to the gfortran front-end in 2007. A ChangeLog
for a multi-author patch is credited to the first listed name. The
number of commits by committer are:
Rafael Avila de Espindola 3
Janne Blomqvist 9
Steven Bosscher 1
Paul Brook 2
Tobias Burnus 103
Nick Clifton 2
Francois-Xavier Coudert 99
Jerry DeLisle 49
Steve Ellcey 2
Bernhard Fischer 6
Daniel Franke 55
Kaveh R. Ghazi 5
Richard Guenther 7
Richard Henderson 1
Aldy Hernandez 1
Kazu Hirata 7
Jan Hubicka 2
Dominique d'Humieres 1
Daniel Jacobowitz 1
Jakub Jelinek 11
Steven G. Kargl 24
Thomas Koenig 14
Anton Korobeynikov 1
Asher Langton 2
Sandra Loosemore 2
Manuel Lopez-Ibanez 1
H.J. Lu 4
Lee Millward 4
Mark Mitchell 1
Brooks Moses 50
Dirk Mueller 1
Joseph Myers 2
Andrew Pinski 3
Christopher D. Rickett 19
Duncan Sands 1
Roger Sayle 22
Tobias Schlueter 26
Nathan Sidwell 1
Ian Lance Taylor 1
Paul Thomas 113
Kai Tietz 1
Tom Tromey 1
Janus Weil 4
Ralf Wildenhues 1
There were 86 commits to libgfortran in 2007. The number of
commits by committer is as follows:
Janne Blomqvist 9
Paolo Bonzini 1
Tobias Burnus 18
Francois-Xavier Coudert 54
Jerry DeLisle 57
David Edelsohn 3
Steve Ellcey 2
Ben Elliston 2
Bernhard Fischer 2
Daniel Franke 3
Jakub Jelinek 1
Steven G. Kargl 5
Thomas Koenig 22
H.J. Lu 1
Brooks Moses 1
Adam Nemet 1
Rainer Orth 1
Christopher D. Rickett 5
Danny Smith 1
Paul Thomas 1
Kai Tietz 1
Tom Tromey 1
So, in terms of total commits, F-X Coudert is the 2007 champion with
153 commits and Tobias a good runner-up with 121.
Within these commits, over 433 problem reports as listed in Bugzilla
were fixed in fortran and a further 63 in libfortran. The PRs listed
in ChangeLogs were fixed by the following individuals:
(Note that there is some duplication of reports due either to multiple
commits being required to fix a bug or the same bug appearing in the
fortran front-end and in the library.)
Janne Blomqvist
32239 32748 32909 27740 32239 32239
Steven Bosscher
30278
Tobias Burnus
20888 25062 25071 29624 29649 30276 30276 30512 30520 30522
30783 30793 30865 30873 30887 30888 30922 30940 30968 30973
31298 31472 31547 31559 31668 31803 32088 32323 32359 32460
32483 32555 32600 32669 32936 32979 32980 32985 32987 33001
33037 33072 33105 33106 33139 33178 33188 33228 33231 33232
33284 33297 33310 33325 33343 33412 33445 33745 33818 33862
33917 33917 33941 34079 34079 34079 34133 34133 34137 34186
34186 34187 34192 34248 34262 34318 34333 34333 34342 34345
18026 29471 34425 34398 34438 34246 34495 34482 34421 34514
29649 30015 30512 31189 31286 31295 31296 31915 31917 32124
32987 34319 34404 34319 34427 34530
Francois-Xavier Coudert
25252 26682 26682 29459 29459 29600 29600 29649 29784 29828
30285 30430 30446 30611 30655 30720 30723 30780 30820 30834
30877 30933 30947 30948 30964 31119 31120 31184 31189 31198
31201 31202 31203 31262 31270 31299 31304 31399 31400 31587
31591 31608 31612 31627 31629 31645 31675 31725 31764 31781
31974 32027 32035 32036 32046 32357 32594 32611 32860 32902
32933 32937 32938 32979 32989 33054 33066 33073 33095 33105
33221 33288 33502 33502 33522 33528 33529 33538 33592 33596
33636 33739 33739 33881 33957 34028 34083 34084 34108 21185
23138 23272 26253 26893 27107 29649 29828 30007 30611 30723
30947 30964 31001 31189 31202 31202 31210 31270 31286 31296
31299 31304 31335 31607 31675 32021 32021 32035 32357 32611
32933 33054 33077 33079 33386 33469 33583 33698 33795
Jerry DeLisle
18923 18923 25061 30408 30532 30681 30779 31162 31201 31251
31251 31306 31495 31609 31716 31812 31813 32002 32223 32360
32361 32432 32545 32611 32612 32644 32760 32928 33055 33055
33055 33152 33162 33162 33162 33317 33317 33317 33544 33609
33795 33849 34175 34209 34227 34325 34540 30162 30435 30910
30918 31051 31052 31052 31052 31052 31099 31099 31199 31201
31207 31366 31395 31501 31532 31880 31922 31964 32235 32446
32456 32456 32456 32554 32611 32678 32702 32752 33039 33055
33055 33055 33225 33225 33253 33253 33253 33253 33307 33400
33421 33672 33795 33985 33985 33985 34291 34411 34427 34560
Steve Ellcey
30432
Bernhard Fischer
27698 31546
Daniel Franke
17711 20373 22359 24633 24784 25094 25104 28004 29876 29962
30947 30950 31129 31234 31253 31265 31473 31639 31639 31639
31760 31818 31919 31929 31930 32001 32002 32359 32467 32633
32634 32704 32710 32727 32760 32778 32867 32876 32879 32905
32906 32945 34324 34495 34559 34536 34533 34532 22359 30947
34533
Richard Guenther
30223 32140
Dominique d'Humieres
33733
Jakub Jelinek
22244 32550 33739 34247 34359 34359 22244
Steven G. Kargl
30278 30605 30683 30799 31244 32223 32899 32942 32968 32969
34192 34203 34203 34230 33583
Thomas Koenig
30389 30415 30533 30814 30865 30869 31732 32731 32954 32972
33683 34305 34549 30512 30525 30533 30690 30765 30814 30814
30981 31196 31618 32217 32336 32858 32972 32977 33985 34370
34323 34405 34566 34594 22423 33298
Asher Langton
20441
Manuel Lopez-Ibanez
30437
H.J. Lu
33276
Lee Millward
32222 32238 32242 32823
Brooks Moses
18769 28068 30235 30371 30381 30420 30881 30933 30948 30953
31050 31194 31216 31427 31972
Adam Nemet
32495
Rainer Orth
32345
Andrew Pinski
32140
Christopher D. Rickett
32579 32599 32600 32600 32600 32601 32627 32732 32732 32797
32800 32801 32801 32804 33020 33040 33215 33395 33497 33760
32600 32600 32600 32627
Roger Sayle
30400 30404
Tobias Schlueter
17711 18937 20851 20897 25076 30478 31144 31250 31266 31471
32147 33198 33254 33269 33626 33689 33727
Paul Thomas
20863 20882 20896 23232 27996 27998 28172 29389 29389 29396
29397 29400 29507 29606 29712 29786 30283 30284 30319 30400
30407 30408 30410 30476 30481 30514 30531 30554 30554 30554
30625 30626 30660 30660 30746 30865 30870 30871 30872 30873
30875 30876 30878 30879 30880 30882 30883 30887 30888 30922
31011 31086 31154 31160 31163 31193 31197 31200 31204 31205
31209 31211 31214 31214 31215 31217 31219 31222 31229 31257
31258 31292 31293 31320 31404 31474 31483 31494 31540 31550
31564 31608 31608 31609 31620 31630 31630 31692 31711 31726
31867 31879 31994 32047 32088 32103 32156 32157 32236 32298
32302 32464 32472 32526 32613 32634 32634 32665 32682 32689
32703 32724 32727 32827 32842 32875 32880 32881 32903 32926
32962 33233 33241 33254 33334 33337 33370 33376 33499 33541
33541 33542 33542 33542 33550 33554 33566 33568 33646 33664
33686 33727 33733 33749 33811 33850 33897 33986 34008 34080
34231 34335 32129 31487 31213 33888 33998 34438 30284 30626
Tom Tromey
27107
Janus Weil
32535
We keep track of the current gfortran bugs on the the Gfortran
wiki with various links to Bugzilla:
Bug Bashing (status 31 December 2007; incl. some double counting)
Regressions 2 PRs, 1 assigned
PRs where a valid program is rejected or wrong code is produced
15 PRs, 6 assigned (Fortran 95 with default options)
PRs where wrong code is produced 10 bugs (1 assigned)
[often triggered for special cases only]
PRs where a valid Fortran program is not accepted (internal compiler
error, wrongly rejected), wrong code is produced or where the
compile time or memory is excessively high 33 bugs (8 assigned)
PRs where invalid code is accepted or gives an internal compiler
error 26 bugs (2 assigned)
PRs which show where the diagnostics can be improved 73 bugs
(2 assigned)
All reports (bug reports, feature requests etc.): 245 reports
It should be noted, given the complexity of Fortran 95, that these
are very few bugs and that the majority of the reports in Bugzilla
are for improvements or new features.
Gfortran Maintainers December 31st 2007
lin...@sohu.com
I complied gcc-4.3.0-20071228 yesterday and found that libgfortran
couldn't pass if I use gcc's -pipe flag.
after I got rid of that flag, libgfortran passed successfully.
what's wrong?
paul.rich...@gmail.com
Hmmm! Good question - as you will see from my commits, I do not have
much contact with the library. Could you post this to the gfortran
list and, better still, post a report on Bugzilla, please?
Thanks
Paul
Thomas Koenig
> I complied gcc-4.3.0-20071228 yesterday and found that libgfortran
> couldn't pass if I use gcc's -pipe flag.
> after I got rid of that flag, libgfortran passed successfully.
This is a hard to debug without more data.
Please post the exact command lines you used, plus any error
messages, and the output of "gfortran -v". One common error is
to use the "gcc" instead of the "gfortran" command.
Paul van Delst
I cannot think of anything more eloquent to say than: "Wow!"
Oh, and a big thanks to all involved.
cheers,
paulv
lin...@sohu.com
>
> Please post the exact command lines you used, plus any error
> messages, and the output of "gfortran -v". One common error is
> to use the "gcc" instead of the "gfortran" command.
thanks for your reply.
something is wrong with maxloc0_4_r4.c when using -pipe flag to
compile gcc-4.3-20071228. please check it.
I downloaded gcc-4.3-20071228.tar.bz2 from gcc.gnu.org ,then
tar xfj gcc-4.3-20071228.tar.bz2
cd gcc-4.3-20071228; mkdir i95 ; cd i95;
../configure --prefix=/usr/local --enable-languages=c,c++,fortran;
make
my CFLAGS and FFLAGS :
CFLAGS = -pipe -g -fverbose-asm -fbounds-check -O3 -ftree-vectorize -
fvect-cost-model -ftree-vect-loop-version -funroll-all-loops -ftree-
loop-linear -ftree-loop-im -march=pentium4 -mfpmath=sse -mieee-fp
FFLAGS = -ffixed-line-length-none -ffree-line-length-none -fimplicit-
none -frange-check -Waliasing -Wsurprising -fmax-errors=0 -Wimplicit-
interface -Wunused-parameter -Wconversion -Wcharacter-truncation -
Wunderflow -ftree-vectorizer-verbose=2 -fbacktrace -fdump-core -ftree-
parallelize-loops=1 -finit-integer=-9999 -finit-real=nan -finit-
logical=false -finit-character=122 -pipe -g -fverbose-asm -fbounds-
check -O3 -ftree-vectorize -fvect-cost-model -ftree-vect-loop-version -
funroll-all-loops -ftree-loop-linear -ftree-loop-im -march=pentium4 -
mfpmath=sse -mieee-fp
everything went well until compiling libgfortran. it stopped and
reported :
if /bin/sh ./libtool --tag=CC --mode=compile /home/lihui/linux/
toolchain/gcc-4.3-20071228/i95/./gcc/xgcc -B/home/lihui/linux/
toolchain/gcc-4.3-20071228/i95/./gcc/ -B/usr/local/i686-pc-linux-gnu/
bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-
linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -
DHAVE_CONFIG_H -I. -I../../../libgfortran -I. -iquote../../../
libgfortran/io -I../../../libgfortran/../gcc -I../../../libgfortran/../
gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-
prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-
strings -O2 -g -pipe -g -fverbose-asm -fbounds-check -O3 -ftree-
vectorize -fvect-cost-model -ftree-vect-loop-version -funroll-all-
loops -ftree-loop-linear -ftree-loop-im -march=pentium4 -mfpmath=sse -
mieee-fp -MT maxloc0_4_r4.lo -MD -MP -MF ".deps/maxloc0_4_r4.Tpo" -
c -o maxloc0_4_r4.lo `test -f '../../../libgfortran/generated/
maxloc0_4_r4.c' || echo '../../../libgfortran/'`../../../libgfortran/
generated/maxloc0_4_r4.c; then mv -f ".deps/maxloc0_4_r4.Tpo" ".deps/
maxloc0_4_r4.Plo"; else rm -f ".deps/maxloc0_4_r4.Tpo"; exit 1; fi
libtool: compile: /home/lihui/linux/toolchain/gcc-4.3-20071228/i95/./
gcc/xgcc -B/home/lihui/linux/toolchain/gcc-4.3-20071228/i95/./gcc/ -B/
usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -
isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-
pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../libgfortran -
I. -iquote../../../libgfortran/io -I../../../libgfortran/../gcc -
I../../../libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -
std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-
definition -Wextra -Wwrite-strings -O2 -g -pipe -g -fverbose-asm -
fbounds-check -O3 -ftree-vectorize -fvect-cost-model -ftree-vect-loop-
version -funroll-all-loops -ftree-loop-linear -ftree-loop-im -
march=pentium4 -mfpmath=sse -mieee-fp -MT maxloc0_4_r4.lo -MD -MP -
MF .deps/maxloc0_4_r4.Tpo -c ../../../libgfortran/generated/
maxloc0_4_r4.c -fPIC -DPIC -o .libs/maxloc0_4_r4.o
../../../libgfortran/generated/maxloc0_4_r4.c: In function
'maxloc0_4_r4':
../../../libgfortran/generated/maxloc0_4_r4.c:104: error: 'f'
undeclared (first use in this function)
../../../libgfortran/generated/maxloc0_4_r4.c:104: error: (Each
undeclared identifier is reported only once
../../../libgfortran/generated/maxloc0_4_r4.c:104: error: for each
function it appears in.)
../../../libgfortran/generated/maxloc0_4_r4.c: In function
'mmaxloc0_4_r4':
../../../libgfortran/generated/maxloc0_4_r4.c:231: error: 'f'
undeclared (first use in this function)
make[3]: *** [maxloc0_4_r4.lo] error 1
make[3]: Leaving directory `/home/lihui/linux/toolchain/
gcc-4.3-20071228/i95/i686-pc-linux-gnu/libgfortran'
make[2]: *** [all] error 2
make[2]: Leaving directory `/home/lihui/linux/toolchain/
gcc-4.3-20071228/i95/i686-pc-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] error 2
make[1]: Leaving directory `/home/lihui/linux/toolchain/
gcc-4.3-20071228/i95'
make: *** [all] error 2
wind
I try gfortran (snapshot 4.3.0-20071228) on x86_64-mingw32. gfortran fails
with optimization (-O1, -O2 , and -O3), internal compiler error:
segmentation fault. The only way it works is no optimization.
--
Posted via a free Usenet account from http://www.teranews.com
baf
> Thank you for developing gfortran.
>
> I try gfortran (snapshot 4.3.0-20071228) on x86_64-mingw32. gfortran fails
> with optimization (-O1, -O2 , and -O3), internal compiler error:
> segmentation fault. The only way it works is no optimization.
>
>
>
wind
"baf" <b...@nowhere.com> wrote in message
news:d9Xej.85921$YL5....@newssvr29.news.prodigy.net...
> wind wrote:
> .....
> It fails on what code?
>
It fails on every code, even the following simplest program
[program begin]
write(*,*) "Hello World"
end
[program end]
I dump the screen text in the following.
There is no problem for the first command "gfortran -o hello.exe hello.f90".
The second command "gfortran -o hello.exe -O1 hello.f90" fails.
The platform is x86_64-pc-mingw32 on 64-bit XP.
C:\temp\fortran>
C:\temp\fortran>
C:\temp\fortran>
C:\temp\fortran>type hello.f90
write(*,*) "hello World"
end
C:\temp\fortran>gfortran -o hello.exe hello.f90
C:\temp\fortran>gfortran -o hello.exe -O1 hello.f90
hello.f90: In function 'MAIN__':
hello.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
C:\temp\fortran>
C:\temp\fortran>
C:\temp\fortran>
James Van Buskirk
news:477cfc05$0$26064$8826...@free.teranews.com...
> The platform is x86_64-pc-mingw32 on 64-bit XP.
C:\gfortran\clf\test>type test.f90
write(*,*) "hello World"
end
C:\gfortran\clf\test>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran -O1
test.f
90 -otest
C:\gfortran\clf\test>test
hello World
C:\gfortran\clf\test>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../trunk/configure --prefix=/home/FX/win64 --build=i386-pc-ming
w32 --target=x86_64-pc-mingw32 --enable-languages=c,fortran --with-gmp=/home/FX/
local --disable-werror --disable-nls --enable-threads=win32
Thread model: win32
gcc version 4.3.0 20071130 (experimental) [trunk revision 130537] (GCC)
C:\gfortran\clf\test>ver
Microsoft Windows [Version 5.2.3790]
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
lin...@sohu.com
i686-pc-linux-gnu/libgfortran are different with those don't use '-
pipe' flag.
when use '-pipe'
#define GFC_REAL_4_HUGE 3.40282347e38f
when don't use :
#define GFC_REAL_4_HUGE f
wind
"James Van Buskirk" <not_...@comcast.net> wrote in message
news:6JKdnd8GR7yUluDa...@comcast.com...
> C:\gfortran\clf\test>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran -v
> Using built-in specs.
> Target: x86_64-pc-mingw32
> Configured with:
> ../trunk/configure --prefix=/home/FX/win64 --build=i386-pc-ming
>
w32 --target=x86_64-pc-mingw32 --enable-languages=c,fortran --with-gmp=/home
/FX/
> local --disable-werror --disable-nls --enable-threads=win32
> Thread model: win32
> gcc version 4.3.0 20071130 (experimental) [trunk revision 130537] (GCC)
It seems the gfortran, (x86_64-pc-mingw32-gfortran), you have, is a cross
compiler for win64. Please check whether x86_64-pc-mingw32-gfortran can run
on i386-pc-mingw32? If so, that is a cross compiler.
The gfortran, I mentioned before, is a native win64 compiler that cannot run
on 32-bit windows, and is configured
with --build=x86_64-unknown-linux --host=x86_64-pc-mingw32 --target=x86_64-p
c-mingw32. This compiler is not from FX.
Every program I tried with optimization fails. I have tested several
programs without optimization, including windows, multithreaded (but, not
openmp), and non-windows applications, and gfortran works without
optimization.
James Van Buskirk
> The gfortran, I mentioned before, is a native win64 compiler that cannot
> run
> on 32-bit windows, and is configured
> with --build=x86_64-unknown-linux --host=x86_64-pc-mingw32 --target=x86_64-p
> c-mingw32. This compiler is not from FX.
Cool. If you can fix this it would likely be the first native x64
compiler.
James Van Buskirk
> Cool. If you can fix this it would likely be the first native x64
> compiler.
Or maybe not. PGI requires a 64-bit OS for installation of its
64-bit compiler, so it may be native already.
FX
> #define GFC_REAL_4_HUGE 3.40282347e38f
That one is OK.
> when don't use :
> #define GFC_REAL_4_HUGE f
That one is wrong. Somehow, -pipe in your CFLAGS must trip up the build
machinery.
--
FX
FX
> compiler.
gfortran has been compiled natively on Win64 before. I can't do it myself
because I have no access to such machine, but Kai Tietz (among others)
have successfully built it and run it. You can build without -pipe and it
should work fine.
--
FX
FX
I also should have said that I created a bugzilla entry for it:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34669
Thanks for reporting the issue!
--
FX
wind
> Cool. If you can fix this it would likely be the first native x64
> compiler.
>
64-bit gfortran binaries for windows X64 can be downloaded at
www.equation.com
Toon Moene
> Cool. If you can fix this it would likely be the first native x64
> compiler.
On Windows, you probably mean. I use gfortran as a native 64 bit
compiler on GNU/Linux AMD64 now for about 2.5 years.
--
Toon Moene - e-mail: to...@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/ml/gcc/2008-01/msg00009.html
ejk...@gmail.com
> James Van Buskirk wrote:
>
> On Windows, you probably mean. I use gfortran as a native 64 bit
> compiler on GNU/Linux AMD64 now for about 2.5 years.
>
ever had any luck with gfortran for anything other than the
simplest programs. I always encounter a show-stopping problem.
Case in point: I downloaded the latest (Dec. 27) Cygwin build
and tried to compile the Schwartztrauber FFT library
with gfortran -c. The compiler was still running after 4 hours
when I killed it.
--Eric
FX
> any luck with gfortran for anything other than the simplest programs. I
> always encounter a show-stopping problem.
Well, your mileage may vary, and I could tell you that I compile and use
for production quite a few codes with gfortran, most of them far from
being "the simplest programs": cp2k, for example, is 550kloc and quite
F95-intensive, as the number of bugs it has uncovered in different
compilers is quite large.
My question is thus: have you reported any of these bugs? I've been
searching through our bug database, our mailing-list and the whole Google
for your bug reports, and can't find any.
> Case in point: I downloaded the latest (Dec. 27) Cygwin build and tried
> to compile the Schwartztrauber FFT library with gfortran -c. The
> compiler was still running after 4 hours when I killed it.
In particular: have you reported that issue? Simply explain what code you
compile, how exactly you compile it and what happens, and send that to
for...@gcc.gnu.org
--
FX
Toon Moene
> ejkost wrote:
>> I'm reluctant to criticize a volunteer effort, but I've never, ever had
>> any luck with gfortran for anything other than the simplest programs. I
>> always encounter a show-stopping problem.
> Well, your mileage may vary, and I could tell you that I compile and use
> for production quite a few codes with gfortran, most of them far from
> being "the simplest programs": cp2k, for example, is 550kloc and quite
> F95-intensive, as the number of bugs it has uncovered in different
> compilers is quite large.
Ditto over here. I can run both our weather forecasting model HIRLAM (>
1E6 lines of Fortran), using GNU Fortran 4.2.0 (prerelease) since
December 2005 and the new AROME/HARMONIE one (> 2E6 lines) in
operational mode using GNU Fortran 4.3.0 (almost prerelease) - since
half a year.
I always wonder what people actually *do* who manage to get our stuff
"not working", "even on the simplest programs".
Craig Powers
> FX wrote:
>
> > ejkost wrote:
>
>>> I'm reluctant to criticize a volunteer effort, but I've never, ever had
>>> any luck with gfortran for anything other than the simplest programs. I
>>> always encounter a show-stopping problem.
>
>> Well, your mileage may vary, and I could tell you that I compile and use
>> for production quite a few codes with gfortran, most of them far from
>> being "the simplest programs": cp2k, for example, is 550kloc and quite
>> F95-intensive, as the number of bugs it has uncovered in different
>> compilers is quite large.
>
> Ditto over here. I can run both our weather forecasting model HIRLAM (>
> 1E6 lines of Fortran), using GNU Fortran 4.2.0 (prerelease) since
> December 2005 and the new AROME/HARMONIE one (> 2E6 lines) in
> operational mode using GNU Fortran 4.3.0 (almost prerelease) - since
> half a year.
>
> I always wonder what people actually *do* who manage to get our stuff
> "not working", "even on the simplest programs".
>
Well, this:
> I downloaded the latest (Dec. 27) Cygwin build
^^^^^^
might have something to do with it. I seem to recall there being more
than usual issues with convincing Cygwin to work than with just about
any other config.
Come to think of it, it's not even necessarily a gfortran problem,
there's no guarantee that the library configures correctly for Cygwin
either.
pigeon
<ejk...@gmail.com> wrote in message
news:944ad109-09d8-467a...@r60g2000hsc.googlegroups.com...
> I'm reluctant to criticize a volunteer effort, but I've never,
> ever had any luck with gfortran for anything other than the
> simplest programs. I always encounter a show-stopping problem.
> Case in point: I downloaded the latest (Dec. 27) Cygwin build
> and tried to compile the Schwartztrauber FFT library
> with gfortran -c. The compiler was still running after 4 hours
> when I killed it.
>
> --Eric
gfortran is distributed with "make". You can build your library in parallel,
very simple, e.g.,
make -j 4
if you have 4-processor or 4-core computer.
-pigeon-
wind
"FX" <cou...@alussinan.org> wrote in message
news:fm0gdt$1m0g$1...@nef.ens.fr...
> Well, your mileage may vary, and I could tell you that I compile and use
> for production quite a few codes with gfortran, most of them far from
> being "the simplest programs": cp2k, for example, is 550kloc and quite
> F95-intensive, as the number of bugs it has uncovered in different
> compilers is quite large.
>
I am a gfortran user, too.
PS: sorry not to privde a valid email address because I am afraid of
spammer.
Richard Maine
> <ejk...@gmail.com> wrote in message
> news:944ad109-09d8-467a...@r60g2000hsc.googlegroups.com...
> > and tried to compile the Schwartztrauber FFT library
> > with gfortran -c. The compiler was still running after 4 hours
> > when I killed it.
> >
> > --Eric
>
> gfortran is distributed with "make".
Really? I would certainly hope not. I don't generally expect installing
a compiler to mess with other parts of the OS that I would already have
installed. So if I install 4 different compilers, they get to fight over
what version of "make" gets installed? That would be horrible. I have
only rarely used Cygwin, but if things like this are normal for it, I'm
glad I don't.
Perhaps you just mean that "make" is normally available. That would make
a lot more sense.
> You can build your library in parallel,
> very simple, e.g.,
>
> make -j 4
>
> if you have 4-processor or 4-core computer.
I think you miss the whole point. It was not that 1 hour plus unknown
more would have been better than 4 plus unknown more.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
pigeon
"Richard Maine" <nos...@see.signature> wrote in message
news:1iaenzc.kyrvw61hydpt0N%nos...@see.signature...
> > gfortran is distributed with "make".
>
> Really? I would certainly hope not. I don't generally expect installing
> a compiler to mess with other parts of the OS that I would already have
> installed. So if I install 4 different compilers, they get to fight over
> what version of "make" gets installed? That would be horrible. I have
> only rarely used Cygwin, but if things like this are normal for it, I'm
> glad I don't.
The gfortran I have comes with MAKE. MAKE is not a part of gcc, but belongs
to gnu.
If you have 4 different compilers, you can specify the one you plan to use
in makefile. They won't fight. If you have 4 different "make", you can
specify the one you want in environment parameter. I have three different
fortran compilers on my computer.
If you have a big project, try to use parallel build. That cannot give you
100% efficiency. You may receive benifit of dual core or quad core.
-pigeon-
baf
Very strange. I grabbed the fft source (rfft-1.2-ss-90.01.tgz) from
http://www.jjj.de/fft/fftpage.html, put all of the fortran source files
in a directory and typed
gfortran -c *.f
and got all of the source files compiled in a couple of seconds. There
were 4 warning messages about array ifac having out of bound subscript
references, but that is pretty common in old fortran source. For this
test I used 4.3.0 (20070824) i386-pc-mingw32
I would suggest you try the ming32 (native) version rather than the
cygwin version.
Reagan Revision
> ejk...@gmail.com wrote:
>> On Jan 6, 6:34 am, Toon Moene <t...@moene.indiv.nluug.nl> wrote:
>>> James Van Buskirk wrote:
>>>
>>> On Windows, you probably mean. I use gfortran as a native 64 bit
>>> compiler on GNU/Linux AMD64 now for about 2.5 years.
>> I'm reluctant to criticize a volunteer effort, but I've never,
>> ever had any luck with gfortran for anything other than the
>> simplest programs. I always encounter a show-stopping problem.
>> Case in point: I downloaded the latest (Dec. 27) Cygwin build
>> and tried to compile the Schwartztrauber FFT library
>> with gfortran -c. The compiler was still running after 4 hours
>> when I killed it.
>>
>> --Eric
>
> Very strange. I grabbed the fft source (rfft-1.2-ss-90.01.tgz) from
> http://www.jjj.de/fft/fftpage.html, put all of the fortran source files in
> a directory and typed
>
> gfortran -c *.f
>
> and got all of the source files compiled in a couple of seconds. There
> were 4 warning messages about array ifac having out of bound subscript
> references, but that is pretty common in old fortran source. For this
> test I used 4.3.0 (20070824) i386-pc-mingw32
>
> I would suggest you try the ming32 (native) version rather than the cygwin
> version.
I suspect one of two culprits: cygwin or the cygwin-mindset of the windows
user. The former does have issues as one would only imagine. There's a
functioning german language n.g. out there for it.
I might be average in terms of how ham-handed Joe Windows-user feels trying
to get something to work on cygwin. I certainly put plenty of effort into
it, where others might have a background related to it. I don't even know
where the hole in my education is in this regard.
--
Reagan Revision
"We are being told that a competent, trustworthy president is someone
who brandishes his religion like a neon sign, loads a gun and goes out
hunting for beautiful winged creatures, and tries to imitate a past
president who, by the way, never shot a bird or felt the need to imitate
anybody."
~~ Patti Davis Is Not Flattered by GOP Candidates' Pale Imitations of
Her Father
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
FX
>
> Really? I would certainly hope not. I don't generally expect installing
> a compiler to mess with other parts of the OS that I would already have
> installed.
The gfortran package for Windows (based on mingw) includes a few GNU
tools, including make, gdb, etc. You do not have to use them, but as
people want to use this "standalone" package for development and often
don't have GNU developer tools (unlike what is common on MacOS and
linux), I figured out it would be best to provide them. As I said, you
don't have to use them, but they're provided if you wish to.
--
FX
kostel...@gmail.com
> ejk...@gmail.com wrote:
> > On Jan 6, 6:34 am, Toon Moene <t...@moene.indiv.nluug.nl> wrote:
> >> James Van Buskirk wrote:
>
> >> On Windows, you probably mean. I use gfortran as a native 64 bit
> >> compiler on GNU/Linux AMD64 now for about 2.5 years.
>
> > I'm reluctant to criticize a volunteer effort, but I've never,
> > ever had any luck with gfortran for anything other than the
> > simplest programs. I always encounter a show-stopping problem.
> > Case in point: I downloaded the latest (Dec. 27) Cygwin build
> > and tried to compile the Schwartztrauber FFT library
> > with gfortran -c. The compiler was still running after 4 hours
> > when I killed it.
>
> > --Eric
>
> in a directory and typed
>
> gfortran -c *.f
>
> and got all of the source files compiled in a couple of seconds. There
> were 4 warning messages about array ifac having out of bound subscript
> references, but that is pretty common in old fortran source. For this
> test I used 4.3.0 (20070824) i386-pc-mingw32
>
> I would suggest you try the ming32 (native) version rather than the
> cygwin version.
It could well be a problem with the latest Cygwin build (which is
unusable).
While I'm not trying to disparage an honorable effort, it seems to me
that if I can't get gfortran to work, then there must be many others
who can't, either.
I'll try the OSX version on my other machine. Thanks for this
information!
--Eric
FX
> unusable).
> While I'm not trying to disparage an honorable effort, it seems to me
> that if I can't get gfortran to work, then there must be many others
> who can't, either.
I think most of the gfortran Windows users use the "standalone"/"native
Windows" package (mingw build). (The proportion of downloads from
quatramaran.ens.fr is approximately 4 to 1.) Have you thought about
giving it a try, or are you tied to cygwin?
> I'll try the OSX version on my other machine. Thanks for this
> information!
I've tried FFTpack (if that's indeed what you're interested in) on my
MacBook Pro (Intel/MacOS) and it's compiling flawlessly.
--
FX
Tim Prince
I haven't had serious problems either with builds I made from source
(IA-64, x86-64, ia32 linux, cygwin) or got from others (x86-64 linux and
64-bit mingw). I've even seen over 50% of the PRs which I filed fixed.
I've built and tested 2 million source line MPI applications, with
fewer problems (aside from mediocre performance) than pre-release
commercial compilers. Much more than an honorable effort.