This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gfortran] Support INTEGER<->LOGICAL conversion as GNU extension

On Sat, 28 May 2005, FX Coudert wrote:
> I think the main point of gfortran when it comes to options is to
> default to the g77 behavior. I'd go for that too.

I believe a closer interpretation is that "the main point of gfortran
when it comes to options is to default to a *superset* of the g77
behavior".  This is why gfortran enables f95 and f2003 functionality
by default, even though these weren't supported by g77.  It's also why
many of my patches to add similar GNU extensions to g77 were enabled by
default.  Unfortunately, when we stopped developement of g77, I hadn't
implemented all of the features supported by other FORTRAN 77 compilers.

> (not that my opinion has much importance ;-)

Both yours and Steven's opinions are extremely important and if I
can't convince you both to change your minds (or soften your opinions),
I'll concede and rewrite my patch to use -fugly-int.

I should perhaps explain my motivation.  First and foremost I am not
myself a FORTRAN programmer nor does OpenEye Scientific software write
any FORTRAN code.  However for validation purposes, one of our needs
is to validate our algorithms/codes against industry standard reference
implementations that are written in FORTRAN.  One such example is the
semi-empirical quantum mechanics program MOPAC.  Being a reference
(like SPECfp) our hands are tied in that we're not allowed to modify
the original source code lest we invalidate the validation.  Whilst
OpenEye has been happy to use the commercial compilers from SGI, IBM
and HP to build and run programs and confirm our results, as a GCC
contributor the lack of a free (as in speech) compiler solution has
been a blot for us.  Many of my patches to g77 and now gfortran have
been to get to the point where GNU fortran is a viable alternative.
Hence patches for X in format statements, missing commas in formats,
logical to integer interconversion and at some point in the future
supporting the intrinsic "SECOND(1)" were all to this end.

As for g77's -fugly-int which I only recently discovered, adding the
functionality to allow the code to compile somehow is clearly better
than gfortran not being able to compile the code at all.  But in
retrospect, if I'd discovered that the reason I'd been forced to use
commercial compilers for years was purely because I didn't know that
the fatal compiler errors I'd encountered could be resolved with
-fugly-int, I'd be as angry as I was embarassed.  In this case, there's
plenty of other unimplemented/unsupported features in gfortran, but
eventually I'd hope that -fugly-int were a default (as it is with other
compilers), a non-fatal compiler warning, or perhaps that the availability
of the "-fugly-int" command line option was mentioned in the error

Finally, I should comment my appreciation for the hard work of the
gfortran and g95 folks, as the current ability of gfortran to compile
far more of MOPAC than g77 ever could, as an indication of how much
better it is and how far things have improved.  By this metric,
gfortran is within two or three patches of MIPSPro's f77 which compiles
the entire code base without even a single warning.

I also appreciate to a real fortran programmer or for real end-user
usage these constraints seem a little bizarre.  It would be trivial
for someone writing their own code, to add the missing "LOGICAL LIMSF"
between the "COMMON /SCFTYP/ EMIN, LIMSCF" and "LIMSCF=.FALSE." to
resolve this issue, and to change all instances of "SECOND(1)" to

Hopefully OpenEye's expectations of a f77 compiler aren't too


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]