[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

["law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878

--- Comment #15 from Jeffrey A. Law <law at redhat dot com> 2011-01-22 04:03:24 UTC ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/21/11 17:41, dj at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878
> 
> --- Comment #12 from DJ Delorie <dj at redhat dot com> 2011-01-22 00:40:44 UTC ---
> Of course, one could argue that perhaps the compare should *not* have been
> removed?  I don't know how clever the new redundant compare removal code is.
I'm thinking that is the fundamental problem.

This appears to be a HAVE_cc0 target.  On a cc0 target the setter and
user must always remain consecutive.  The reason for that is insns
implicitly set cc0, which isn't reflected in the rtl/dataflow.  So if we
allowed anything in between setter & user it might clobber the flags
unexpectedly.


Prior to combine you have this:

(code_label 20 17 21 4 2 "" [1 uses])

(note 21 20 22 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(insn 22 21 23 4 (set (cc0)
        (compare (reg:SI 43 [ D.1959 ])
            (const_int 1 [0x1]))) test.c:10 16 {cmpsi_insn}
     (expr_list:REG_DEAD (reg:SI 43 [ D.1959 ])
        (nil)))

(insn 23 22 60 4 (set (reg/v:SI 44 [ c ])
        (ne:SI (cc0)
            (const_int 0 [0]))) test.c:10 40 {*setcc}
     (nil))


Everything looks fine and dandy.  The cc0 setter and cc0 user are
consecutive insns.

After combine you have:

(code_label 20 17 21 4 2 "" [1 uses])

(note 21 20 22 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(note 22 21 23 4 NOTE_INSN_DELETED)

(insn 23 22 60 4 (set (reg/v:SI 44 [ c ])
        (ne:SI (cc0)
            (const_int 0 [0]))) test.c:10 40 {*setcc}
     (nil))

(note 60 23 59 4 NOTE_INSN_DELETED)


Even if insn 22 was redundant on the paths leading to code_label 20, on
a HAVE_cc0 target, the cc0 setter and cc0 user must remain consecutive
insns thus deleting insn 22 is incorrect.


So, you need to track down why combine decides it's OK to delete insn 22.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNOlb2AAoJEBRtltQi2kC778wH/3fsKS9yq2BBqjK1cWFHbbkp
1IqAwk2cZAOYLWgtAIrmRKkoUAIKi7rqKzNfvy7qWJwtpLavX1SvQ69e4EBtc67R
ZdSq05H3n1MzU6tRx/TcF/SjMlO0vAct/AOSI6TvHK59eZGoYGSa0Mqaqw7LQCT+
zX4aT2x09w/tNA4qJgBLoEEw71dIfEszACz9F3T6k2ZMIHjyPQoBzt7k0YKGOcDU
0uv89djEHVmvr0mFkF7k5Pn/RlytibDVy/43aKUCmflWvsj7BsOkrKfruHDSdGtI
Yg9Zd2MPCDQ2gHrN0VaxOFITjwgMf9takt4gJYqKGOJMFcyiiaFlKSAgQlt0/bs=
=xVgr
-----END PGP SIGNATURE-----