[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-fortran
Subject:    Re: [fortran, patch] Allow displaying backtraces from user code
From:       Janus Weil <janus () gcc ! gnu ! org>
Date:       2012-04-24 13:04:15
Message-ID: CAKwh3qjT6nLhEttaP6=im=C5DZEJMwKecbrEvGoF8ihmazij=g () mail ! gmail ! com
[Download RAW message or body]

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. =A0The patch
>> starts us down a slippery slope. =A0Why not export all
>> the nonstandard intrinsics? =A0In additions, the
>> _gfortran_ prefix was used to separate the libgfortran
>> namespace from userspace. =A0Providing a means to
>> circumvent this separation seems to asking for more
>> PR.
>
> Well, the mean exists. All _gfortran_* functions can already be called, t=
hey're part of libgfortran's public (and versioned) API. I'm just saying ad=
ding 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. =A0The 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 int=
rinsic 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
[prev in list] [next in list] [prev in thread] [next in thread]