This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [fortran, patch] Allow displaying backtraces from user code


Hi guys,

(coming back to an old patch proposed by FX some time ago ...)

2012/3/3 FX <fxcoudert@gmail.com>:
>> 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
>> PR.
>
> 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.

Cheers,
Janus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]