On 01/29/2012 07:57 AM, Tom de Vries wrote:
Richard,
[now cc-ing gcc-patches]
this patch fixes PR50283 in a target-independent way.
it asserts on frame-related insns in the delay slot of insns that can throw,
and prevents the assert by testing for the same condition in
On 01/29/2012 07:57 AM, Tom de Vries wrote:
Richard,
[now cc-ing gcc-patches]
this patch fixes PR50283 in a target-independent way.
it asserts on frame-related insns in the delay slot of insns that can
throw, and prevents the assert by testing for the same condition in
On 01/30/2012 11:07 AM, Paul Brook wrote:
However this is a issue of debug experiance rather than code correctness. My
guess is most architectures don't allow you to singlestep into delay slots,
so
any use of delay slots may cause lossage[1], not just frame related ones.
Certainly Sparc
On 01/30/2012 11:07 AM, Paul Brook wrote:
It's worth noting that -fasync-unwind-tables does not guarantee
backtrace/unwind from arbitrary points. Only from those instructions that
may
result in a synchronous trap (which matches the semantics of this patch).
... and we're not talking about
On 01/30/2012 11:07 AM, Paul Brook wrote:
It's worth noting that -fasync-unwind-tables does not guarantee
backtrace/unwind from arbitrary points. Only from those instructions
that may result in a synchronous trap (which matches the semantics of
this patch).
... and we're not talking
Richard,
[now cc-ing gcc-patches]
this patch fixes PR50283 in a target-independent way.
it asserts on frame-related insns in the delay slot of insns that can throw,
and prevents the assert by testing for the same condition in
eligible_for_{delay,annul_true,annul_false}.
build and reg-tested on
