Janne Blomqvist wrote:
> I disagree with the ERROR STOP change.
My thinking is that the spirit of ERROR STOP is that the program
noticed something went seriously wrong (e.g. program state corrupted
in some way), and hence a backtrace and/or core dump might help
figure out what went wrong. For less serious errors, there's the plain
STOP. Similar to how in C there's exit() and abort().
Well, typical usages would be:
STOP "Calculation finished"
and
ERROR STOP "No input file found"
Admittedly, STOP is also used for the latter as there was no ERROR STOP
until Fortran 2008 - and when using numerical arguments, the value is
also used as exit status code - with string values, which are rather
common, STOP has always the success exit status code 0.
Especially with coarrays, one cannot easily prevent the usage of ERROR
STOP: Assume that this_image() > 1 processes wait for process 1 ("SYNC
IMAGES(1)") to read in the data and to broadcast it. Now, process 1 sees
that there is no input file - what shell it do? A STOP would cause a
dead lock. Thus, one simply calls ERROR STOP "No input file" - and does
not want to have a backtrace ...
As written, before if one is able to call STOP or ERROR STOP, one knows
where one is in the program - and at least roughly why one stops there.
Thus, at least by default, I don't want to have a backtrace. If one had
a "-fbacktrace=always" or similar, one could still backtrace ERROR STOP
- and maybe even STOP ;-)
Maybe, we should make the backtrace functionality available like other
compilers have; looking at our code, I find for Intel
USE ifcore
CALL tracebackqq(USER_EXIT_CODE=-1)
and for IBM
CALL xl__trbk()
Tobias
