Gfortran 2 years behind G95 and still not ready for prime time 
Author Message
 Gfortran 2 years behind G95 and still not ready for prime time

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.  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://www.*-*-*.com/ ; 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://www.*-*-*.com/ ; 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://www.*-*-*.com/ ; for instructions.

C:\mingw\geloe>gfortran -c -fdollar-ok utility.f90



Tue, 01 Sep 2009 04:24:27 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

Quote:

>Warning: Obsolete: PAUSE statement at (1)

If you want to avoid this, you can use -std=legacy.

Quote:

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

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

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

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

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



Tue, 01 Sep 2009 05:09:17 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

Quote:


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

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



Tue, 01 Sep 2009 05:43:56 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

Quote:


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



Tue, 01 Sep 2009 07:33:28 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time
OK here's some more details:

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.



Tue, 01 Sep 2009 07:37:48 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

(snip on Q format specifier)

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



Tue, 01 Sep 2009 08:42:36 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

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



Tue, 01 Sep 2009 09:20:58 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

Quote:


> (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.

Quote:
> It might be that DEC used it for the record size input.

Yes, I think it is a DEC feature.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain



Tue, 01 Sep 2009 09:21:09 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time


Quote:
> 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 {*filter*} 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.

--
Steve
http://www.*-*-*.com/ ~kargl/



Tue, 01 Sep 2009 10:09:22 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

Quote:

> OK here's some more details:
> 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.

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.

Quote:
> 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! :) )

Quote:
> 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,
- Brooks

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



Tue, 01 Sep 2009 12:25:16 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

Quote:
> PPS: Count the number of times the word "regression" (or some
> 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



Tue, 01 Sep 2009 15:43:12 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

Quote:
> I'm not sure what the point is for the exercise

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:

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



Tue, 01 Sep 2009 16:27:52 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

(snip)

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



Tue, 01 Sep 2009 18:17:09 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time
Gfortran development "by committee" should not be doing any extensions
(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



Tue, 01 Sep 2009 18:06:27 GMT  
 Gfortran 2 years behind G95 and still not ready for prime time

Quote:
> Gfortran development "by committee" should not be doing any extensions
> (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.

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

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



Tue, 01 Sep 2009 18:46:05 GMT  
 
 [ 41 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Is Squeak ready for prime time?

2. Is C4b ready for Prime Time?

3. Is ruby ready for prime time?

4. VRML 2.0 Ready for Prime Time?

5. Win2k ready for prime time?

6. Is 1.6 ready for prime time?

7. Common statement does not work with gfortran, but g95 gives the correct answer

8. automatic arrays with negative size in g95 and gfortran

9. gfortran or g95

10. gfortran vs. g95

11. difference between g95 and gfortran

 

 
Powered by phpBB® Forum Software