[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 amylaar@gcc.gnu.org:
>
> http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00640.html
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
Reply to: