[fortran, patch] Allow displaying backtraces from user code

Janus Weil janus@gcc.gnu.org
Fri Dec 14 14:31:00 GMT 2012


Hi all,

here is another attempt to make gfortran support user-requested backtraces.

A patch in this direction was already proposed by FX in March, but did
not make it in so far. It was last discussed in June, cf.
http://gcc.gnu.org/ml/fortran/2012-06/msg00131.html and follow-ups,
where the consensus seemed to be to add a new intrinsic subroutine for
this (as GNU extension).

This is just what the attached patch does: It exports
_gfortran_show_backtrace from libgfortran and adds an intrinsic
SHOW_BACKTRACE, together with some documentation in intrinsic.texi (it
also documents the fact that ABORT gives a backtrace recently).

Ok for trunk?

Cheers,
Janus


2012-12-14  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/36044
    * gfortran.h (gfc_isym_id): Add GFC_ISYM_SHOW_BACKTRACE.
    * intrinsic.c (add_subroutines): Add "show_backtrace".
    * intrinsic.texi (SHOW_BACKTRACE): Document SHOW_BACKTRACE intrinsic.


2012-12-14  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/36044
    * gfortran.map: Add _gfortran_show_backtrace.
    * libgfortran.h: Export show_backtrace.
    * runtime/backtrace.c: Ditto.




2012/6/21 Janus Weil <janus@gcc.gnu.org>:
>>> There are two possibilities:
>>> a) Making _gfortran_show_backtrace accessible from the outside (via manual
>>> C binding from Fortran)
>>> b) Adding a new intrinsic
>>>
>>
>> I would vote for b), as it gets documented then.
>> It is enough useful for a wide range of programmers to deserve
>> an intrinsic of its own, IMHO.
>> And always directly available, no need of module convolutions.
>
> As noted before, I also prefer b).
>
>
>> Name: simply show_backtrace ?
>> This would be a self-explaining name, the odd "QQ" in
>> tracebackqq is just this, odd.
>> And why call it traceback when it is actually a backtrace ;-)
>
> Adopting the name from Intel would have the advantage of compatibility
> between ifort and gfortran. However, since other vendors have
> different names, compatibility between several compilers in this
> non-standard function will not be realized. Moreover I agree that the
> 'QQ' part is odd (I never understood what it is supposed to mean).
>
> Therefore I would also vote for something like "show_backtrace" (or
> simply "backtrace"?).
>
> Cheers,
> Janus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr36044_backtrace_intrinsic.diff
Type: application/octet-stream
Size: 3914 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20121214/5002754b/attachment.obj>


More information about the Gcc-patches mailing list