From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5932 invoked by alias); 10 Dec 2010 15:45:58 -0000 Received: (qmail 5899 invoked by uid 22791); 10 Dec 2010 15:45:55 -0000 X-SWARE-Spam-Status: No, hits=-2.8 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; Fri, 10 Dec 2010 15:45:47 +0000 From: "vmakarov at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/46829] ICE: in spill_failure, at reload1.c:2105 with -fschedule-insns -fsched-pressure and variadic function 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: vmakarov at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned 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 Date: Fri, 10 Dec 2010 15:45: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: 2010-12/txt/msg01125.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829 --- Comment #10 from Vladimir Makarov 2010-12-10 15:45:33 UTC --- (In reply to comment #9) > (In reply to comment #5) > > It should work for x86_64, not necessarily i?86. > > Do you mean -fsched-pressure should be able to solve the problem completely > for x86-64? > > Vladimir: Do you have any idea which direction to go in order to solve this > problem? Introducing of -fsched-pressure just decreased probability of the bug when 1st insn scheduling is used. The patch introducing -fsched-pressure contained some code in reload to decrease the probability even more. Unfortunately, it did not eliminated it fully. This bug can not be fixed in scheduler (or the solution, like not moving through insn referring for a hard register, will be too conservative especially for x86_64 and still will not fix it for x86) because the scheduler can not see all info handled by reload. IMHO, the right fix should be possibility to split live ranges for explicitly mentioned hard register. May be Jeff Law's current work will provide such feature. In any case, implementation of live range splitting in reload is too big and complicated job even for stage #1. There is no way to implement it at stage #3. It is also very unreasonable thing to do because any change in reload is usually very bug prone. I am sorry, but I don't see that it can be fixed for gcc4.6 fox x86/x86-64. Although it might be fixed for gcc4.7.