From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5449 invoked by alias); 22 Jan 2011 04:03:59 -0000 Received: (qmail 5434 invoked by uid 22791); 22 Jan 2011 04:03:58 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 22 Jan 2011 04:03:43 +0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: blocker X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: dj at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Sat, 22 Jan 2011 09:40:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg02295.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 --- Comment #15 from Jeffrey A. Law 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 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-----