On Thu, Oct 22, 2015 at 5:14 PM, Bernd Schmidt wrote:
> On 10/22/2015 05:08 PM, Bernd Schmidt wrote:
>
>> So I'm not entirely sure yet what's supposed to happen here, but I think
>> the problem could well be in the expansion phase.
>
>
> Forgot to mention another possibility that crossed my mind:
On 10/22/2015 05:08 PM, Bernd Schmidt wrote:
So I'm not entirely sure yet what's supposed to happen here, but I think
the problem could well be in the expansion phase.
Forgot to mention another possibility that crossed my mind: don't
compare locations for equality in fixup_reorder_chain, inst
On 10/22/2015 04:19 PM, Nick Clifton wrote:
It is in cfgrtl.c:fixup_reorder_chain()
nb = split_edge (e);
if (!INSN_P (BB_END (nb)))
BB_END (nb) = emit_insn_after_noloc (gen_nop (), BB_END (nb),
nb);
INSN_LOCATION (BB_END (nb)) = e->goto_lo
Hi Bernd,
Could you point me at the code generating these NOPs
It is in cfgrtl.c:fixup_reorder_chain()
nb = split_edge (e);
if (!INSN_P (BB_END (nb)))
BB_END (nb) = emit_insn_after_noloc (gen_nop (), BB_END (nb),
nb
Hi Nick,
On 10/22/2015 04:07 PM, Nick Clifton wrote:
Sometimes gcc can generate instructions out of order with respect to
lines of source code, and this can lead to problems for debuggers.
For example, consider this source code snippet:
v = 0; /* Line 31 */
Hi Guys,
Sometimes gcc can generate instructions out of order with respect to
lines of source code, and this can lead to problems for debuggers.
For example, consider this source code snippet:
v = 0; /* Line 31 */
goto b;/* Line 32 */
a: v++;
