Hi guys, (coming back to an old patch proposed by FX some time ago ...)
2012/3/3 FX <fxcoud...@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
