------- 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 [EMAIL PROTECTED]: > > 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
