Gfortran 2 years behind G95 and still not ready for prime time
awgre...@earthlink.net
application without ICEs let alone other errors. G95 has been
handling this code properly for 2 years. The code also compiles and
runs fine using LF95 7.1, IVF, and IBM XLF.
On the plus side, the ICEs are down to just 2 distinct ones (although
both appear to have been in their bug list for a long time):
C:\mingw\geloe>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw --enable-
languages=c,fortran --with-gmp=/home/coud
Thread model: win32
gcc version 4.3.0 20070315 (experimental)
C:\mingw\geloe>for %f in (*.f90) do gfortran -c -fdollar-ok %f
C:\mingw\geloe>gfortran -c -fdollar-ok advanced.f90
C:\mingw\geloe>gfortran -c -fdollar-ok analysis.f90
C:\mingw\geloe>gfortran -c -fdollar-ok binaries.f90
C:\mingw\geloe>gfortran -c -fdollar-ok coherent.f90
C:\mingw\geloe>gfortran -c -fdollar-ok control.f90
C:\mingw\geloe>gfortran -c -fdollar-ok dialogs.f90
dialogs.f90:40.78:
pause 'Error reading dialog -- Hit return to check edits and try
again'; clo
1
Warning: Obsolete: PAUSE statement at (1)
C:\mingw\geloe>gfortran -c -fdollar-ok exparser.f90
exparser.f90:0: internal compiler error: in
gfc_conv_array_initializer, at fortran/trans-array.c:3693
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
C:\mingw\geloe>gfortran -c -fdollar-ok exportas.f90
C:\mingw\geloe>gfortran -c -fdollar-ok exports.f90
C:\mingw\geloe>gfortran -c -fdollar-ok fastfour.f90
fastfour.f90:5.45:
complex(KR),intent(inout) :: cdat(numb,abs(mode))
1
Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type
fastfour.f90:39.45:
complex(KR),intent(inout) :: cdat(numb,abs(mode))
1
Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type
fastfour.f90:78.45:
complex(KR),intent(inout) :: cdat(numb,abs(mode))
1
Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type
C:\mingw\geloe>gfortran -c -fdollar-ok gelement.f90
C:\mingw\geloe>gfortran -c -fdollar-ok geloe.f90
modules.f90:710: internal compiler error: in
gfc_conv_array_initializer, at fortran/trans-array.c:3693
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
C:\mingw\geloe>gfortran -c -fdollar-ok graphics.f90
C:\mingw\geloe>gfortran -c -fdollar-ok implicit.f90
C:\mingw\geloe>gfortran -c -fdollar-ok imports.f90
C:\mingw\geloe>gfortran -c -fdollar-ok inreader.f90
inreader.f90:86.55:
read(abs(lu),'(q,a)',iostat=i) l,line(:min(l,m)); m=min(l,m) !
faster but
1
Warning: Unexpected element in format string at (1)
C:\mingw\geloe>gfortran -c -fdollar-ok mechanic.f90
C:\mingw\geloe>gfortran -c -fdollar-ok modules.f90
C:\mingw\geloe>gfortran -c -fdollar-ok optical.f90
C:\mingw\geloe>gfortran -c -fdollar-ok property.f90
C:\mingw\geloe>gfortran -c -fdollar-ok raytrace.f90
raytrace.f90:97.25:
dimension pos(3,0:nint(dis)),vec(3)
1
Error: 'a' argument of 'nint' intrinsic at (1) must be REAL
C:\mingw\geloe>gfortran -c -fdollar-ok readasap.f90
C:\mingw\geloe>gfortran -c -fdollar-ok readlens.f90
C:\mingw\geloe>gfortran -c -fdollar-ok routines.f90
C:\mingw\geloe>gfortran -c -fdollar-ok scatter.f90
C:\mingw\geloe>gfortran -c -fdollar-ok sources.f90
C:\mingw\geloe>gfortran -c -fdollar-ok strings.f90
strings.f90: In function 'numoccurances':
strings.f90:198: internal compiler error: in fold_binary, at fold-
const.c:8975
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
C:\mingw\geloe>gfortran -c -fdollar-ok utility.f90
Thomas Koenig
>Warning: Obsolete: PAUSE statement at (1)
If you want to avoid this, you can use -std=legacy.
>
>C:\mingw\geloe>gfortran -c -fdollar-ok exparser.f90
>exparser.f90:0: internal compiler error: in
>gfc_conv_array_initializer, at fortran/trans-array.c:3693
>Please submit a full bug report,
>with preprocessed source if appropriate.
Can you provide a reduced test case?
>C:\mingw\geloe>gfortran -c -fdollar-ok fastfour.f90
>fastfour.f90:5.45:
>
> complex(KR),intent(inout) :: cdat(numb,abs(mode))
> 1
>Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type
>fastfour.f90:39.45:
What is "mode" declared as? Can you post a small example?
> read(abs(lu),'(q,a)',iostat=i) l,line(:min(l,m)); m=min(l,m) !
>faster but
> 1
>Warning: Unexpected element in format string at (1)
q is a non-standard specifier for quadruple precision.
>raytrace.f90:97.25:
>
> dimension pos(3,0:nint(dis)),vec(3)
> 1
>Error: 'a' argument of 'nint' intrinsic at (1) must be REAL
What is "dis" declared as?
>C:\mingw\geloe>gfortran -c -fdollar-ok strings.f90
>strings.f90: In function 'numoccurances':
>strings.f90:198: internal compiler error: in fold_binary, at fold-
>const.c:8975
>Please submit a full bug report,
>with preprocessed source if appropriate.
>See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Can you post a small example?
Thanks!
Brooks Moses
> <awgre...@earthlink.net> wrote:
>> C:\mingw\geloe>gfortran -c -fdollar-ok exparser.f90
>> exparser.f90:0: internal compiler error: in
>> gfc_conv_array_initializer, at fortran/trans-array.c:3693
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>
> Can you provide a reduced test case?
I expect this is the bug about using TRANSFER in initializers, PR 18796.
>> C:\mingw\geloe>gfortran -c -fdollar-ok strings.f90
>> strings.f90: In function 'numoccurances':
>> strings.f90:198: internal compiler error: in fold_binary, at fold-
>> const.c:8975
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> Can you post a small example?
I can't find any evidence of this one in the bug database, despite the
claim that this one has "been in the bug database for a long time", so
more details would definitely be useful here.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
Richard Maine
> <awgre...@earthlink.net> wrote:
> > read(abs(lu),'(q,a)',iostat=i) l,line(:min(l,m)); m=min(l,m) !
> >faster but
> > 1
> >Warning: Unexpected element in format string at (1)
>
> q is a non-standard specifier for quadruple precision.
It is nonstandard, but not for something so simple as quad precision. In
this context, I think it is a more esoteric nonstandard feature. I
forget the details, but I think it was something about counting the
record size or some such thing. Lots of compilers don't support that
one.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
awgre...@earthlink.net
1. I'm not worried about the WARNINGS (I would be if they were
missing!)
2. MODE and DIS are subroutine arguments of default (i.e. not
explicitly declared) integer and real, respectively. This is not
"modern" Fortran but valid Fortran just the same.
3. The one ICE in fold_binary (fold-const.c) seems to be one involving
TRANSFER
function NumOccurances(string,chr) result(n)
character(*),intent(in) :: string
character(1),intent(in) :: chr
!
! return number of occurances of character in given string
!
n=count(transfer(string,char(1),len(string))==chr)
return
end
4. The other ICE is related to the use of LEN_TRIM (and maybe also
INDEX) as an elemental in an integer array intializer.
glen herrmannsfeldt
(snip on Q format specifier)
> It is nonstandard, but not for something so simple as quad precision. In
> this context, I think it is a more esoteric nonstandard feature. I
> forget the details, but I think it was something about counting the
> record size or some such thing. Lots of compilers don't support that
> one.
OS/360 Fortran, at least since the 360/85, has Q for REAL*16 and
COMPLEX*32. (Hardware on the 360/85 and I believe all 370's,
otherwise done in software on the illegal opcode exception.)
It might be that DEC used it for the record size input.
-- glen
Steve Lionel
> OS/360 Fortran, at least since the 360/85, has Q for REAL*16 and
> COMPLEX*32. (Hardware on the 360/85 and I believe all 370's,
> otherwise done in software on the illegal opcode exception.)
>
> It might be that DEC used it for the record size input.
In this context, it is the DEC extension to "read" the number of
remaining characters in the record.
Steve
Richard Maine
> Richard Maine wrote:
>
> (snip on Q format specifier)
>
> > It is nonstandard, but not for something so simple as quad precision. In
> > this context, I think it is a more esoteric nonstandard feature. I
> > forget the details, but I think it was something about counting the
> > record size or some such thing. Lots of compilers don't support that
> > one.
>
> OS/360 Fortran, at least since the 360/85, has Q for REAL*16 and
> COMPLEX*32. (Hardware on the 360/85 and I believe all 370's,
> otherwise done in software on the illegal opcode exception.)
Could be. But that is clearly not applicable to the context shown.
> It might be that DEC used it for the record size input.
Yes, I think it is a DEC feature.
Steven G. Kargl
awgre...@earthlink.net writes:
> The latest Gfortran (Windows) release still cannot compile my
> application without ICEs let alone other errors. G95 has been
> handling this code properly for 2 years.
Seems you've had 2 years to download, find, and fix the bugs
that have caused you so much pain. Of course, I guess it is
easier to bitch and moan that others aren't making your life
a stroll in the park.
If g95 meets your needs, then by a means use it. What's the
point in the comparison to g95 meant to achieve? Other than
to draw the ire of those who actually contribute to gfortran.
PS: I know one approach to fix your TRANSFER problem. Guess
what? I'm not paid to fix this problem and it will take a
significant amount of effort to fix problem.
PPS: Count the number of times the word "regression" (or some
variation) appears on the g95 home page.
Brooks Moses
> explicitly declared) integer and real, respectively. This is not
> "modern" Fortran but valid Fortran just the same.
That does sound like a bug. I can't reproduce it with the following
obvious test program, however; could you please provide a reduced test case?
---------------------------------------
subroutine mysub1(mode, dis)
write (*,*) abs(mode), nint(dis)
end subroutine
program testprog
call mysub1(-2, 3.2)
end
---------------------------------------
The above prints 2 and 3, as expected.
> 3. The one ICE in fold_binary (fold-const.c) seems to be one involving
> TRANSFER
>
> function NumOccurances(string,chr) result(n)
> character(*),intent(in) :: string
> character(1),intent(in) :: chr
> !
> ! return number of occurances of character in given string
> !
> n=count(transfer(string,char(1),len(string))==chr)
> return
> end
Indeed. (And thanks for the small test case here; I can reproduce that
one.) That doesn't appear to be related to the constant-folding, though
it may be.
I'll make sure this is in our bug database. If it does turn out to be
related to the constant-folding, it's also one of the next bugs that I'm
planning to work on fixing. (Note that I am currently writing my
dissertation, though, which should give you a reasonable estimate of the
ETA for a fix! :) )
> 4. The other ICE is related to the use of LEN_TRIM (and maybe also
> INDEX) as an elemental in an integer array intializer.
The INDEX portion of that seems likely to be related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29507, which was first
reported four months ago. It looks like there is some progress on a
fix, though.
I can't find any evidence in the bug database that we've heard of the
LEN_TRIM problem before, though. Could you provide a small sample
program for that, which produces the ICE but doesn't involve INDEX?
One of the things that may not be immediately be clear -- but should, I
hope, be clear from this exchange -- is that GFortran is very dependent
on individual users for bug reports. According to our database, there
are 43 known unfixed "bugs" in GFortran that result in problems with
valid code. Right now, those are effectively the only 43 bugs of that
sort that we can try to fix. Thus, we really do appreciate the effort
that people put into submitting helpful bug reports.
Thanks,
Joost
> variation) appears on the g95 home page.
I'm not sure what the point is for the exercise, but
'grep -i regression' on the blog for the period 2000-2007 returns 292
lines, while the same word searched in the gfortran mailing list
(2003-2007) appears
3637 times in 1610 messages. Furthermore, g95 has since august last
year a stable version, which might not contain some of the newer
features (e.g. extended iso_c_binding support) of the current
snapshot, but is otherwise perfectly fine for all typical Fortran 95
codes.
Joost
FX
I think Steve wanted to point out a feeling we've been sharing while
looking at the g95.org blog every once in a while: modifications to g95
appear to induce regressions at a rate that seemed a bit high.
While you (and the OP) complain about the low pace at which gfortran
evolves (and we all agree that, given more hands, it could evolve
faster), it might be a good point to note that a slower pace, with actual
patch reviews before commiting, might have other avantages.
Although I don't think there is any way, given information available, to
actually put numbers on that feeling, I have one point about your count:
> 'grep -i regression' on the blog for the period 2000-2007 returns 292
> lines, while the same word searched in the gfortran mailing list
> (2003-2007) appears 3637 times in 1610 messages.
You can't pretend to compare word counts on a mailing-list archive and a
daily one-person blog. I count over 1700 messages on the list from the
beginning of the year, against 46 blog entries in the same time.
--
FX
glen herrmannsfeldt
> On Mar 15, 8:42 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
(snip)
> In this context, it is the DEC extension to "read" the number of
> remaining characters in the record.
It seems that VMS still has it:
http://h71000.www7.hp.com/doc/82final/6324/6324pro_048.html#q_edit
VAX has quad precision (H-float), but no exponent specific format
descriptor for it. In newer Fortran versions, as far as I can tell,
either D or E can be used for real data of any precision. I don't
see that Fortran 66 allows D with REAL data. I am not so sure about
using E with double precision data. Presumable VMS allows E,
and possibly D, for quad precision data.
-- glen
awgre...@earthlink.net
(e.g. Openmp) before achieving a standard conforming compiler with no
known bugs.
In terms of bug reporting and squashing, I have become spoiled by the
direct communication with and quick turnaround provided by Andy Vaught
of G95. Gfortran's mechanism seems slow, clumsy, and impersonal.
To be fair, there have been times when my code stopped compiling on
G95 but the "downtime" was usually only a day or two. Also, I am
currently riding the Intel people over regressions in IVF so don't
take any of this personal.
I have always wanted Gfortran to succeed but I'm just disappointed by
its progress. I would contribute except that I am strictly an end-user
(i.e. a Fortran programmer, not a compiler writer).
Al Greynolds
www.ruda.com
FX
> (e.g. Openmp) before achieving a standard conforming compiler with no
> known bugs.
Well, the OpenMP development was not done by anyone of the "usual
gfortran development team" but rather by other GCC contributors, namely
RedHat employees. When a company offers such a great contribution (the
OpenMP patch was of excellent overall quality), it would be pointless to
let it down. RedHat decides where it wants to spend its effort wrt GCC,
and they decided to spend it on OpenMP at some point. I'm personnaly glad
they did.
> gfortran's mechanism seems slow, clumsy, and impersonal.
Maybe because GCC has a very different overall scale than the g95
project? gfortran is part of GCC, and it has advantages and
disadvantages, for both the user and developpers. I think that the
overall impact is, for both users and developpers, positive.
> I have always wanted Gfortran to succeed but I'm just disappointed by
> its progress. I would contribute except that I am strictly an end-user
> (i.e. a Fortran programmer, not a compiler writer).
Well, there's great value in contributions from advanced end-users like
you and others on comp.lang.fortran. It goes from testing the codes you
write and use and bug-reporting, to helping with documentation, packaging
and distribution. You can also help by adding gfortran support to
software you use, providing Fortran software developpers with Makefiles
and build scripts that use gfortran as compiler and suitable options.
All of this takes time, from little to much depending on what you do
exactly. But volunteering is the way volunteer projects continue to exist
:)
--
FX
Brooks Moses
> Gfortran development "by committee" should not be doing any extensions
> (e.g. Openmp) before achieving a standard conforming compiler with no
> known bugs.
"By committee" is, unfortunately, an inaccurate picture of how a lot of
open-source software, such as GFortran, is developed. For example,
OpenMP was not included because the development team, as a committee,
formed a consensus to develop it. It was included because one or two
people felt that it would be useful to include in GCC as a whole, and
wrote an implementation of it (including both C and Fortran portions),
and contributed it. At that point, the only committee decision, really,
was whether or not to include it.
Similarly, the "Cray"-pointer support was included essentially because
LLNL felt it was worthwhile to hire someone to write it, presumably
because they wanted it for their own codes. And the C-interop
implementation currently in progress is largely being written by someone
from LANL.
Thus, it's a rather poor model to assume that there are a fixed number
of programmer-hours that will be spent on developing GFortran, which can
be allocated by the development team to whatever is considered the
highest priority. Beyond the matter of people who are donating specific
functionality, it's also worth noting that most of the developers are
"paid" only in the enjoyment of contributing, and fixing bugs is notably
less fun than implementing new things; thus, if one were to restrict
contributors only to fixing bugs, the net time spent on bug-fixing would
likely go down rather than up!
With that said, though, I think if you were to look at the code
submitted by the core development team in the last year or so, you'll
find that the vast bulk of it is indeed bug-fixes and implementations of
missing core functionality.
> In terms of bug reporting and squashing, I have become spoiled by the
> direct communication with and quick turnaround provided by Andy Vaught
> of G95. Gfortran's mechanism seems slow, clumsy, and impersonal.
Andy is quite remarkable, yes. :)
It would be difficult to approximate his capabilities even if we also
had someone working on GFortran full-time, but currently I don't know of
anyone who has the ability to spend more than a few hours a week on it.
> I have always wanted Gfortran to succeed but I'm just disappointed by
> its progress. I would contribute except that I am strictly an end-user
> (i.e. a Fortran programmer, not a compiler writer).
Well, financial donations would also be gladly accepted. I would be
glad of a few months of short full-time employment post-graduation,
while I'm looking for a permanent job. :)
And, as I said earlier, detailed bug reports with testcases also help,
even if it does take us a while to get to them.
awgre...@earthlink.net
the years would have been availability of up-to-date binaries. Again
as an end-user, I have NEVER built a compiler from source and really
don't have any interest in doing it. G95 provides up-to-date binaries
for dozens of platforms. Gfortran should have been doing this long
ago. I always felt that it seemed somewhat futile to report a bug if
it took weeks or months before a patched binary would be available.
P.S. I have contributed financially to the G95 development as reward
for Andy's amazing efforts.
Joost
Steven G. Kargl) very inappropriate. Whereas, depending on your
personal view of code development, regressions can be bad, the number
of open bugs that really affect people is much more of an issue. I've
now added to bugzilla PRs 31196 to 31211, which are N cases where
gfortran compiles a code, but generates wrong code. They all work fine
with g95, and this also seems the case with most of the 50 or so open
bugs I have in bugzilla. I do appreciate the work of gfortranners, but
it seems better to stay out of comparisons for a while.
Joost
awgre...@earthlink.net
subroutine mysub1(a,b,mode,dis) !this doesn't work
!subroutine mysub1(mode,dis,a,b) !this does
dimension a(abs(mode)),b(int(dis))
glen herrmannsfeldt
It may work, but I don't believe it is legal.
If you make a and b optional arguments I might believe it.
-- glen
awgre...@earthlink.net
I don't see what the OPTIONAL attribute has to do with this ex\ample.
I believe it is legal Fortran or at least every other compiler I use
thinks it is. The order of the arguments should make absolutely no
difference here but obviously Gfortran is sensitive to it.
FX
I think you didn't post the code you wanted to post. The following code,
on the other hand:
subroutine mysub1(a,b,mode,dis)
dimension a(abs(mode)),b(int(dis))
print *, mod
write (*,*) abs(mode), nint(dis)
end subroutine
program testprog
call mysub1((/1.,2./),(/1.,2.,3./),-2, 3.2)
end
is in my opinion legal, and gfortran doesn't compile it unless you add
the following declarations:
integer :: mode
real :: dis
We have a bugreport open (with a patch submitted a few days ago) about
implicit typing of such args, I'll need to check if it's the same problem
here or not (I have to go now, will check later today).
--
FX
glen herrmannsfeldt
>>I don't see what the OPTIONAL attribute has to do with this example.
The one my follow up was from only had two arguments to mysub1.
> I think you didn't post the code you wanted to post. The following code,
> on the other hand:
> subroutine mysub1(a,b,mode,dis)
> dimension a(abs(mode)),b(int(dis))
> print *, mod
> write (*,*) abs(mode), nint(dis)
> end subroutine
> program testprog
> call mysub1((/1.,2./),(/1.,2.,3./),-2, 3.2)
> end
> is in my opinion legal, and gfortran doesn't compile it unless you add
> the following declarations:
> integer :: mode
> real :: dis
If you don't have IMPLICIT NONE that is strange, but the
one I replied to only had two arguments to mysub1, presumably mode and
dis, which is why I commented about optional arguments.
> We have a bugreport open (with a patch submitted a few days ago) about
> implicit typing of such args, I'll need to check if it's the same problem
> here or not (I have to go now, will check later today).
-- glen
glen herrmannsfeldt
> On Mar 16, 5:45 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>>awgreyno...@earthlink.net wrote:
>>>Try this variation of your program:
>>>subroutine mysub1(a,b,mode,dis) !this doesn't work
>>>!subroutine mysub1(mode,dis,a,b) !this does
>>> dimension a(abs(mode)),b(int(dis))
>>> write (*,*) abs(mode), nint(dis)
>>>end subroutine
>>>program testprog
>>> call mysub1(-2, 3.2)
>>>end
>>If you make a and b optional arguments I might believe it.
> I don't see what the OPTIONAL attribute has to do with this ex\ample.
> I believe it is legal Fortran or at least every other compiler I use
> thinks it is. The order of the arguments should make absolutely no
> difference here but obviously Gfortran is sensitive to it.
It was a follow up to your post that only had two arguments.
Maybe you missed with cut and paste, and there were supposed to be four.
I agree that order shouldn't matter.
-- glen
awgre...@earthlink.net
arguments so I now see why OPTIONAL was brought up. I was actually
just compiling the subroutine by itself to generate the bug.
Al
Richard Maine
> The point is more that I find the tone of some message... very inappropriate.
...
> I do appreciate the work of gfortranners, but
> it seems better to stay out of comparisons for a while.
I tend to agree. There are people who I regard as personal friends
working on both gfortran and g95. I wish both camps the best.
I think it reflects poorly (or, as Joost says, the tone is
inappropriate) when someone working on one of the products criticizes
the "competing" one. Leave that to the users. Maybe its just me, but
such criticisms often leave me with a poorer opinion of the criticiser
than of the intended target. (Oddly, that's my reaction to most
political ads also... of all parties).
I've tried both gfortran and g95 at various times. They both have
clearly advanced and are better than they once were. I think I'll not
make comparisons between the two at the moment. Try both; it doesn't
take much to do so. If one of them isn't being easy to install, that
itself can be part of the trial.
Brooks Moses
> Try this variation of your program:
>
> subroutine mysub1(a,b,mode,dis) !this doesn't work
> !subroutine mysub1(mode,dis,a,b) !this does
> dimension a(abs(mode)),b(int(dis))
> write (*,*) abs(mode), nint(dis)
> end subroutine
Thank you; that does indeed produce an error here as well. Looks like
we're not resolving implicit types early enough, or something like that.
Brooks Moses
> I've now added to bugzilla PRs 31196 to 31211, which are N cases where
> gfortran compiles a code, but generates wrong code.
Thank you muchly for tracking all of those down.
Dick Hendrickson
> In article <YYY>,
> ZZZ writes:
>> The latest Gfortran (Windows) release still cannot compile my
>> application without ICEs let alone other errors. G95 has been
>> handling this code properly for 2 years.
>
> Seems you've had 2 years to download, find, and fix the bugs
> that have caused you so much pain. Of course, I guess it is
> easier to bitch and moan that others aren't making your life
> a stroll in the park.
>
>
> PPS: Count the number of times the word "regression" (or some
> variation) appears on the g95 home page.
>
Interestingly enough I have a F95 test suite that Steve Lionel
recently called "brutal" right here in this very forum. A
couple or five or so years ago one of the g* Fortran people asked
me if I would try the suite on that particular compiler. I was
busy at the time and didn't get a round to it. As time went on,
I read several posts on this very forum and decided that a pox on both
there houses wasn't anywhere near adequate.
I'm going to have some significant free time in a couple of months.
One of the many advantages of being a grumpy old fart.
I don't know a lot about OSs, I don't know a lot about windows.
I'd need some significant handholding to get either compiler up and
running on my new Windows XP machine. Could anyone tell me why
I should bother? It will be hard (I don't think either compiler will
be able to compile the (F90 compliant) framework, let alone the
8000+ tests). Why would a sane person step into this sniping?
Dick Hendrickson
Charles Russell
> I'm going to have some significant free time in a couple of months.
> One of the many advantages of being a grumpy old fart.
> Why would a sane person step into this sniping?
It gives an old fart something to grump about.
Do a favor for another old fart and see how these compilers compare on
netlib code. Mature f77 compilers included a lot of features to
accomodate outdated coding practices; how about these new kids on the block?
Beliavsky
<snip>
> Interestingly enough I have a F95 test suite that Steve Lionel
> recently called "brutal" right here in this very forum. A
> couple or five or so years ago one of the g* Fortran people asked
> me if I would try the suite on that particular compiler. I was
> busy at the time and didn't get a round to it. As time went on,
> I read several posts on this very forum and decided that a pox on both
> there houses wasn't anywhere near adequate.
>
> I'm going to have some significant free time in a couple of months.
> One of the many advantages of being a grumpy old fart.
> I don't know a lot about OSs, I don't know a lot about windows.
> I'd need some significant handholding to get either compiler up and
> running on my new Windows XP machine. Could anyone tell me why
> I should bother? It will be hard (I don't think either compiler will
> be able to compile the (F90 compliant) framework, let alone the
> 8000+ tests). Why would a sane person step into this sniping?
Installing the Mingw (stand-alone) versions of g95 and gfortran is
simple for both compilers. If you have trouble with the former, please
post your problems here (or even better the gg95 Google Group
http://groups.google.com/group/gg95) and for a change, maybe someone
can help YOU.
Why should you bother? I think the Fortran community has benefitted
greatly from your advice in this forum over the years (at least I
have!) and your service on the standards committees, and your
debugging of the g95 and gfortran compilers will also be appreciated
and similarly well paid :). In particular the g95 developer fixes
demonstrated noncompliance with the Fortran 95 standard quickly. I
dare you to break g95 :).
I would not take gfortran/g95 sniping too seriously. Many people use
both compilers and submit bug reports to both sets of developers.
There was a split, but as Clive Page observes at http://www.star.le.ac.uk/~cgp/fortran.html
, it may have been for the best.
Beliavsky
> Do a favor for another old fart and see how these compilers compare on
> netlib code. Mature f77 compilers included a lot of features to
> accomodate outdated coding practices; how about these new kids on the block?
I think that gfortran, the successor of g77, aims to compile
(1) all code that g77 did (Fortran 77 and certain extensions) and
(2) all standard Fortran 95 (and eventually Fortran 2003) code.
G95 has aim (2) but is selective about (1). For example, real-valued
do loop variables were present in Fortran 77 but removed from Fortran
95, and the primary developer of g95 has decided not to implement
them . Therefore g95 does not compile the original SLATEC, for
example. In some ways gfortran and g95 are complementary.
John Burkardt has translated SLATEC to Fortran 95, using free source
form and removing real-valued loop variables, so that it now compiles
with g95. The translated SLATEC code and test suite is at
http://people.scs.fsu.edu/~burkardt/f_src/slatec/slatec.html . Bad
programming practices should not be enshrined forever.
Thomas Koenig
>I have always wanted Gfortran to succeed but I'm just disappointed by
>its progress. I would contribute except that I am strictly an end-user
>(i.e. a Fortran programmer, not a compiler writer).
Speaking from personal experience, you don't have to have super
programming powers to contibrute to gfortran. Contributing and
simplifying bug reports helps a lot. If you want to delve into the
library, you need nothing more than a good working knowledge of C
(because both compiler and library are written in C) and, of
course, Fortran.
Brooks Moses
> On Mar 16, 4:33 pm, Charles Russell <NOS...@bellsouth.net> wrote:
>> Do a favor for another old fart and see how these compilers compare on
>> netlib code. Mature f77 compilers included a lot of features to
>> accomodate outdated coding practices; how about these new kids on the block?
>
> I think that gfortran, the successor of g77, aims to compile
> (1) all code that g77 did (Fortran 77 and certain extensions) and
> (2) all standard Fortran 95 (and eventually Fortran 2003) code.
This is almost completely true; however, in a few small (and, we hope,
rare) cases, there are extensions from g77 that aren't going to be
implemented in GFortran.
For instance, the FSEEK intrinsic from g77 has an optional
alternate-return argument. That's the only intrinsic with such a thing,
and it would require a substantial amount of code to implement support
for intrinsics with alternate-return arguments (especially optional
ones!), and I don't think anyone feels that it's worth the effort.
In addition, while g77 did have quite a lot of legacy support, there are
some things that it didn't support. The use of variable names within
format strings as references to the values of those variables has been
discussed here a few times, as one example that GFortran isn't likely to
support just because the code to support it would be large, crufty, and
painful to maintain for what is perceived as very little gain.
However, aside from the few minor exceptions, it is generally true that
GFortran is intended to support virtually anything that g77 is
documented to support. I think it does a reasonably good job of
supporting legacy code as well, though I'd be rather interested in
hearing independent data on that -- especially things in the form of "X%
of code in NETLIB can be compiled with GFortran, and the failures are
primarily due to features Y, Z, Q, and BLEEBLETHORP57."
Joost
> I'd need some significant handholding to get either compiler up and
> running on my new Windows XP machine. Could anyone tell me why
> I should bother? It will be hard (I don't think either compiler will
> be able to compile the (F90 compliant) framework, let alone the
> 8000+ tests).
It should be relatively easy to get g95 running on a windows
machine...
basically, download the installer and click to accept the defaults:
http://ftp.g95.org/g95-MinGW.exe
at the same time you might also want to browse the manual
http://ftp.g95.org/G95Manual.pdf
in particular the MinGW section
If you would have problems to do some basic windows stuff needed for
running g95 (opening dos windows, setting shell variables), you can
always get help at:
http://groups.google.com/group/gg95
> Why would a sane person step into this sniping?
to see, with some amazement, g95 pass 7920 of these tests without
problems ;-)
Cheers,
Joost
Kamaraju S Kusumanchi
I remember reading something like "you need to sign a paper and mail it
somewhere before your patches will be accepted in gcc/gfortran etc.," Is
this (still) true? I initially wanted to contribute to gfortran, but the
procedure of signing documents and posting them looked beaurocratic enough
that I restricted myself to bug reports...
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
Brooks Moses
> Thomas Koenig wrote:
>> Speaking from personal experience, you don't have to have super
>> programming powers to contibrute to gfortran. Contributing and
>> simplifying bug reports helps a lot. If you want to delve into the
>> library, you need nothing more than a good working knowledge of C
>> (because both compiler and library are written in C) and, of
>> course, Fortran.
>
> I remember reading something like "you need to sign a paper and mail it
> somewhere before your patches will be accepted in gcc/gfortran etc.," Is
> this (still) true? I initially wanted to contribute to gfortran, but the
> procedure of signing documents and posting them looked beaurocratic enough
> that I restricted myself to bug reports...
It's still true (for things more than a few lines), for all FSF/GNU
software. However, it's a one-time thing -- essentially, it's a
copyright assignment agreement, by which you give the FSF the copyrights
to all code that you develop for the compiler, and assure them that you
don't have an employer agreement that would conflict with such.
FX
> called "brutal" right here in this very forum.
From what I understand, it's not available, and you wouldn't send it to
people interested, even privately?
--
FX
paul.rich...@gmail.com
NumOccurances(string,chr) result(n) bug
see - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31193
I will submit in a day or so, once I have fixed another transfer bug
that investigation of yours uncovered.
Have a nice day
Paul
Dick Hendrickson
have paid a fee for it. I don't feel right about giving it to some
people and charging others for it.
For now, I'll experiment with it on the two compilers as a hobby.
I do appreciate the several offers of help on making Windows work
that I've received.
Dick Hendrickson
Beliavsky
wrote:
<snip>
> I do appreciate the several offers of help on making Windows work
> that I've received.
You do realize that for both compilers, binaries are available for
many operating systems, including Linux and MacOS. For gfortran
Windows builds have typically lagged Linux builds, although FX has
said the lag will be smaller in the future.