Re: Fortran exceptions

From: Mehmet Erol Sanliturk <m.e.sanliturk_at_gmail.com>
Date: Sat, 11 Dec 2021 14:15:33 UTC
On Sat, Dec 11, 2021 at 4:46 PM Daniel Feenberg <feenberg@nber.org> wrote:

>
> On Fri, 10 Dec 2021, Doug Hardie wrote:
>
> > I have a fairly large fortran program that I am trying to run on flang.
> > It almost works, but I am sure there are a few typos in it.  I had to
> > enter it by hand from a large listing.  When it encounters a STOP, it
> > displays several ieee exception messages.  Unfortunately there is no way
> > to identify where those occurred.  How can I get the runtime to stop
> > when an exception occurs.  This is on FreeBSD 13.0 release with whatever
> > flang is in the ports.
>
> I have found valgrind helpful with gfortran - I don't know if it works
> with flang.
>
>     https://valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes
>
> Flang can apparently generate code suitable for the gdb debugger, which
> can be useful.
>
>     https://www.sourceware.org/gdb/
>     https://undo.io/resources/debugging-fortran-code-gdb/
>     https://www.scivision.dev/fortran-debugging-gdb/
>
>
> Finally, if you can use gfortran, there are many options to improve
> runtime checking. You might be interested in --fpe-trap.
>
>     https://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html
>
> As far as I can tell, flang has no equivalents, but I haven't used flang.
> It wouldn't install for me from ports or pkg's. Both complained my version
> of Freebsd (12.1) was unsuitable.
>
> Back in the 1970s there used to be the Watfor-77 compiler for the IBM 360,
> and later for Windows, which would check for uninitalized variables,
> subscripts out of range, type mismatches in subroutine calls, etc and
> provide a clear error message with no need to interpret hex constants. But
> compiler writers don't like to provide what they consider to be crutches
> for people less competent than themselves, so runtime error checking is
> usually neglected, sometimes vigorously. The IBM Fortran G compiler I
> first used in 1972 ran in 16K and provided a better error traceback than
> any currently available compiler I am familiar with except one:
>
>     https://www.silverfrost.com/
>
> Silverfrost does detect and report most runtime errors, but it is Windows
> only.  Worth the money for many users, if you can stand working in
> Windows. The debugged program can go back to FreeBSD.
>
> This question might better go in a fortran-specific mailing list:
>
>     https://groups.google.com/g/comp.lang.fortran
>     https://fortran-lang.discourse.group/
>
> Daniel Feenberg
> NBER





I have used the Silverfrost free compiler for many years in the past .
It is an usual compiler in the following sense :

It is giving errors in many syntaxes which are not errors in Fortran .
For example  ( from MEMORY after many years , but concepts are true ) :

Double Precision  X , Y

.
.
.

If ( X .EQ. Y ) ...
Error : In floating point , equality of X and Y may  not be possible due to
trailing bits generated randomly in electronic circuits

Then , "correct" statement is :

If ( DABS ( X - Y ) .LT.   1.0D-100  <--------- A threshold value  or
variable for  ZERO ... ) ...


And other such very useful messages which related to the "pitfalls" of
possible , undetectable errors by "eye" .

This means that , a program compiled with Silverfrost and run
( its run time errors are corrected ) is likely that it will work correctly
when compiled with
other compilers in any operating system .


Especially "thank you" to Daniel Feenberg for his very nice message .

With my best regards ,


Mehmet Erol Sanliturk