This is the mail archive of the
mailing list for the GCC project.
Re: [fortran, patch] Allow displaying backtraces from user code
- From: Janus Weil <janus at gcc dot gnu dot org>
- To: FX <fxcoudert at gmail dot com>
- Cc: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>, fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Tue, 24 Apr 2012 15:04:15 +0200
- Subject: Re: [fortran, patch] Allow displaying backtraces from user code
- References: <61B50068-0CDB-48AF-95D8-1139D6283FF8@gmail.com> <20120303154145.GA51246@troutmask.apl.washington.edu> <44709FBF-8618-4B76-BAA8-16EB713A2F54@gmail.com>
(coming back to an old patch proposed by FX some time ago ...)
2012/3/3 FX <firstname.lastname@example.org>:
>> I think that this approach is a mistake. ?The patch
>> starts us down a slippery slope. ?Why not export all
>> the nonstandard intrinsics? ?In additions, the
>> _gfortran_ prefix was used to separate the libgfortran
>> namespace from userspace. ?Providing a means to
>> circumvent this separation seems to asking for more
> Well, the mean exists. All _gfortran_* functions can already be called, they're part of libgfortran's public (and versioned) API. I'm just saying adding a simple backtrace function to that list is useful, and documenting it too.
Yes, I agree that this is useful, and in that sense the patch is ok
from my side ...
>> I would rather see a new intrinsic procedure add to
>> gfortran. ?The standard does not prevent a vendor
>> from offer additional intrinsic procedures not found
>> in the standard.
> I just think multiplicating vendor intrinsics makes our life harder. I'd like to hear other's opinions on this issue, but I'll implement the new intrinsic if that's the consensus.
... but I also think that having an intrinsic function for it would be
useful, so that one can just call it without the detour via
ISO_C_BINDING. Note that ifort also has a vendor intrinsic for this,
called TRACEBACKQQ, so we're in good company.