[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns

[amylaar at gcc dot gnu dot org]

------- 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