[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.

Reply to: