[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns
------- Additional Comments From amylaar at gcc dot gnu dot org 2005-09-19 21:04 -------
(In reply to comment #3)
> A regression hunt on i686-linux showed the failure starting with this patch
> from firstname.lastname@example.org:
If the lreg dump is still sane that indicates that the problem was not
caused, by the patch, merely a latent bug was triggered. emit_no_conflict_block
should not be called during reload. to double-check, you can set a breakpoint
on emit_no_conflict_block when reload starts.
However, while looking for possible connections, I found that emit_libcall_block
has a similar bug as emit_no_conflict_block used to have, i.e. it ignores the
result of SETs if an insn has more than one.
FWIW, emit_libcall_block is used in i386.c in legitimize_tls_address, which in
turn is used in ix86_expand_move, which is used by the i386.md move expanders,
which are used by emit_move_insn_1, which is used by gen_move_insn, which
is used by gen_reload.
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.