This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New CSE2 bug on release branch demonstrated by g77
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: New CSE2 bug on release branch demonstrated by g77
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 12 Jun 2001 19:58:46 -0700
- cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, rth at redhat dot com
I understand what is going wrong now.
The important part is:
(insn 232 299 237 (set (reg/v:DF 84)
(const_double:DF (const_int 0 [0x0]) 0 [0x0] 1076101120
[0x40240000] [10])) -1 (nil)
(nil))
...
(insn 246 244 248 (set (reg:DF 139)
(reg:DF 33 f1)) -1 (nil)
(insn_list:REG_RETVAL 241 (expr_list:REG_EQUAL (expr_list
(symbol_ref:SI ("erfc[DS]"))
(expr_list (reg/v:DF 84)
(nil)))
(nil))))
The additional call to life_analysis removes insn 232, which is
dead, but does not update the REG_EQUAL note. (This bizarre-looking
REG_EQUAL note is inserted by the libcall-emission code; it represents
the entire libcall sequence.) So, CSE2 gets confused.
There does not seem to be an easy fix. There's no easy way to
even know which REG_EQUAL notes are talking about which instructions;
if we scanned the instruction stream, we would have a hard time
knowing which notes to remove. But leaving the dead instruction
in is pretty silly, too.
Richard do you have any good ideas?
In the meanwhile, I am going to revert my patch, and reopen the PR,
downgraded to medium priority.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com