From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16028 invoked by alias); 14 Feb 2012 06:57:05 -0000 Received: (qmail 16019 invoked by uid 22791); 14 Feb 2012 06:57:04 -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; Tue, 14 Feb 2012 06:56:51 +0000 From: "abel at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/52203] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7136 with -fsel-sched-pipelining -fselective-scheduling2 and other custom flags Date: Tue, 14 Feb 2012 06:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: abel at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: abel at gcc dot gnu.org 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 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: 2012-02/txt/msg01385.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52203 --- Comment #8 from Andrey Belevantsev 2012-02-14 06:56:10 UTC --- Sorry, I didn't explain clearly from the start. Regarding the backend, I just wanted to double check that for the given insn not having a reservation is correct. Now that Uros confirmed this, I can proceed with the scheduler patch. Uros and Steven, regarding the big picture, you can read the thread on PR 49014, starting from http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01801.html (our first discussions with Bernd) and initial patch with the remainder of the thread at http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00045.html. Basically, we allow insns that recog as >=0 but do not change the DFA state, such insns do not get counted against issue rate. I was wondering whether we could mark such insns specially in the MD files and then assert that any other real insn should affect the DFA. The reason for this was that at least three real backend bugs (missing DFA attributes) were fixed due to the more strict checking the selective scheduler makes wrt the Haifa scheduler. Suprisingly, I could bootstrap x86-64 with just some hours of work with the patch from http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00045.html (the patch marks the offending insns with the new attribute and adds an assert; Uros, if you can spot any insns there that indeed should have a reservation, I can make a patch fixing those). However, at the time I gave in pursuing this work further, as nobody was very fascinated with the idea and I didn't have much free time.