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 agai
On Wed, Dec 19, 2012 at 5:23 PM, 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.
>
> Great, thank
>> 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
> http://gcc.gnu.or
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
http://gcc.gnu.org/wiki/GFortran#GCC
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
On Sun, Dec 16, 2012 at 12:50 AM, Janus Weil 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
>> no
>>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 s
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 t
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 conv
On Sat, Dec 15, 2012 at 6:04 PM, Janus Weil wrote:
>> - I'd prefer to reverse the name, e.g. BACKTRACE_{SHOW,PRINT,SPLURGE},
>> to make it more "discoverable" when browsing the manual.
>> BACKTRACE_PRINT would have the advantage of matching backtrace_print()
>> from libbacktrace, but then again th
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 ma
On Fri, Dec 14, 2012 at 4:31 PM, Janus Weil 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.
> http://gcc.gnu.org/m
Btw: Forgot to mention that it regtests cleanly and the docu parts
were tested with make pdf.
Cheers,
Janus
2012/12/14 Janus Weil :
> 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 di
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 consen
>> 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 intrins
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 t
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
Hi guys,
(coming back to an old patch proposed by FX some time ago ...)
2012/3/3 FX :
>> 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 libg
> 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 see
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 doe
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 t
21 matches
Mail list logo
