I would like to make a module with subroutines for prognostic messages and it would be nice if the prognostic routine would know who is calling. Something like:
SUBROUTINE John()
REAL, PARAMETER :: x = 3.1415
CALL Prognostic_ShowValue(x)
END SUBROUTINE John
where calling subroutine John would result in a message “John says that x = 3.1415”
Of course, I can add a name tag to all my subroutines and pass that name to the subroutine too, but that may not be necessary. How to accomplish this?
There were recent additions to the standard to allow you to get things like compiler name and version but I don’t know about subroutine name. There is a pre-processor macro (FILE) that is set by some compilers that you can use but that means you have to enable preprocssing for your source files (either explicitly or just rename your files to have a .F or .F90 file extension.
Here is an C include file I use mimic the C assert function in source files. It just calls a user supplied subroutine called assert but passes the file name and the current line number (LINE)
We have a proposal in the works for an intrinsic function that returns the current program unit name, usable in constant expressions. At least among the committee members who discussed this at the February meeting (JoR subgroup), we all agreed that this would be a handy thing. This proposal hasn’t yet been fleshed out, but I expect it will be for the June meeting.
This would be very helpful. Over 2500 character constants exist in our newly released library, whose sole purpose is to achieve this functionality manually and painfully (because it involves copy-pasting unit names in strings). Having line and file indicators similar to __LINE__ and __FILE__ would also be very helpful. We have used these two macros over 5,500 times in this library. The portability of these FPP extensions is another issue that we had to invest some thinking to bypass.
A related feature provided by some compilers allows generating a stacktrace, optionally exiting. Where supported this is a very useful diagnostic tool. Is any traceback function included in the proposal?
ifx(1) has tracebackqq(), for example:
program testit
implicit none
write(*,*)'commence'
call a()
write(*,*) 'finish'
contains
subroutine a()
call b()
end subroutine a
subroutine b()
use ifcore
call tracebackqq(string="Done with pass 1", user_exit_code=-1)
end subroutine b
end program testit
It is a shame. Once people can easily access the procedure names a stack trace is so useful people will implement it with a linked list or some other pop/push, probably conditionally and far less efficiently than the compiler/loader could, creating a lot of duplicate efforts.
I already have seen codes that manually pass the name of the caller procedure to the callee to provide this. I would guess there were be several fpm(1) projects as soon as the feature is in Fortran to create libraries for generating a stack trace using the proposed feature.
It does seem many Fortran compilers provide at least an optional backtrace ability; albeit often only at low optimization and with symbol tables available. That indicates it might not be too big an ask to make it standard at least in some “conditionally available” way; but most (all?) of the system interface procedures like date_and_time are only optionally required to fully function.
Symbolic backtraces require a lot of information to be added to the executable in ways that tend to be implementation-specific. I know that for DVF we had to invent this out of whole cloth, as the MS toolchain had no concept. Yes, if you are in the debugger you can leverage debug info for this, but not generally for production code.
Yes; but having a method of doing a stacktrace is important enough that the first four compilers I surveyed all had a method of doing it. That seems to indicate it would not be an unreasonable burden to add it as an optional standard interface; and that is is valuable to do so. As soon as ERROR STOP was introduced the implementations I saw produced a trace much like is common with abort(). That fact that it was implemented from whole cloth for DVF suggests it is important enough to a programming language
to make available even if it is difficult, it seems. So many things are implemented like this by nearly every compiler including something like POSIX interfaces that always hold people back from using Fortran. It will at least be better than it was to have file, line number, and procedure name available; and it took decades to just get a standard method for obtaining the date and time (and timezone is still not handled in a standard way) so glad to see some forward movement. But it is so natural to do so that once the constants are available people will construct ways to get a backtrace with them; and there will likely be a lot of duplicate code generated. Anyone thinking about using the 2023 features is almost immediately going to be figuring out how to use it to get a stack trace.