Re: Fortran exceptions
- In reply to: Daniel Feenberg : "Re: Fortran exceptions"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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