Attached is a new patch, which expands the documentation according to
your proposal, and uses the name BACKTRACE. I hope that both Janne and
Tobias can agree with this naming decision ...
Looks fine from my side.
Great, thanks. Janne?
Yes, Ok for trunk.
Thanks again to both of you.
On Sun, Dec 16, 2012 at 12:50 AM, Janus Weil ja...@gcc.gnu.org wrote:
Hi,
So, in principle I'm fine with all your BACKTRACE_* variants (except
for _splurge, maybe ;)
Or, why not just (plain and simple) BACKTRACE?
The name is the same as backtrace() in glibc, but otherwise, sure why
not.
Hi,
first off: Some more words on the naming issue. I actually still
prefer the most simple and straightforward variant (i.e. BACKTRACE,
which can easily be found and does not sound 'clumsy') ...
Or, why not just (plain and simple) BACKTRACE?
The name is the same as backtrace() in glibc, but
Janus Weil wrote:
Attached is a new patch, which expands the documentation according to
your proposal, and uses the name BACKTRACE. I hope that both Janne and
Tobias can agree with this naming decision ...
Looks fine from my side. Can you also add a quip to
Attached is a new patch, which expands the documentation according to
your proposal, and uses the name BACKTRACE. I hope that both Janne and
Tobias can agree with this naming decision ...
Looks fine from my side.
Great, thanks. Janne?
Can you also add a quip to
Janus Weil wrote:
So, in principle I'm fine with all your BACKTRACE_* variants (except
for _splurge, maybe;)
Or, why not just (plain and simple) BACKTRACE?
The name is the same as backtrace() in glibc, but otherwise, sure why
not. _show/_print might be preferable in the sense that they convey
So, in principle I'm fine with all your BACKTRACE_* variants (except
for _splurge, maybe;)
Or, why not just (plain and simple) BACKTRACE?
The name is the same as backtrace() in glibc, but otherwise, sure why
not. _show/_print might be preferable in the sense that they convey
that stuff
On Fri, Dec 14, 2012 at 4:31 PM, Janus Weil ja...@gcc.gnu.org wrote:
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.
Hi Janne,
here is another attempt to make gfortran support user-requested backtraces.
[...]
Ok for trunk?
Some comments.
thanks for your comments ...
- I'd prefer to reverse the name, e.g. BACKTRACE_{SHOW,PRINT,SPLURGE},
to make it more discoverable when browsing the manual.
Hi,
So, in principle I'm fine with all your BACKTRACE_* variants (except
for _splurge, maybe ;)
Or, why not just (plain and simple) BACKTRACE?
The name is the same as backtrace() in glibc, but otherwise, sure why
not. _show/_print might be preferable in the sense that they convey
that
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
On 03/03/2012 08:44 AM, FX wrote [1]:
PR 36044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044) is an enhancement
request for a way to display backtraces from user code.
I wanted to come back to that patch for some while. I think it makes
sense to offer this feature in some why and as the
Am 21.06.2012 14:15, schrieb Tobias Burnus:
On 03/03/2012 08:44 AM, FX wrote [1]:
PR 36044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044) is an enhancement
request for a way to display backtraces from user code.
I wanted to come back to that patch for some while. I think it makes sense
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
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
On Sat, Mar 03, 2012 at 08:44:56AM +0100, FX wrote:
PR 36044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044) is an
enhancement request for a way to display backtraces from user code. I'm
against adding yet another nonstandard intrinsic for this purpose (which is
how Intel Fortran does
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
PR 36044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044) is an enhancement
request for a way to display backtraces from user code. I'm against adding yet
another nonstandard intrinsic for this purpose (which is how Intel Fortran does
it), but I would like to offer the following solution to
18 matches
Mail list logo
