From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104826 invoked by alias); 10 Apr 2015 15:53:13 -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 Received: (qmail 102920 invoked by uid 48); 10 Apr 2015 15:53:09 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf Date: Fri, 10 Apr 2015 15:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: ice-on-valid-code, ra X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-04/txt/msg00867.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729 --- Comment #6 from Jakub Jelinek --- (In reply to Vladimir Makarov from comment #5) > (In reply to Yvan Roux from comment #4) > > For me the assertion in prohibited_class_reg_set_mode_p is not right, it > > checks that set is a subset of reg_class_contents[rclass] and my > > understanding is that it should be the opposite: > > > > lra_assert (hard_reg_set_subset_p (reg_class_contents[rclass],set)); > > > > With this modification the test is fixed (full validation is ongoing). > > > > Do I miss something Vlad ? > > After some investigation done, I believe you are right, Yvan. > this_alternative_set is always not smaller than contents of this_alternative > as we use reg_class_subunion. So you can submit your patch with swapping > arguments in the assert call, of course after testing on x86-64 at least. I > am approving the patch. If you don't respond it in a few hours, I'll do it > myself. Thanks. > > By the way, it is a bad practice for RA not define classes which are union > of classes can be used for the same operand. In this case, we could use > GENERAL_REGS or VFP_LO_REGS but only VFP_LO_REGS will be used only as it is > a result of reg_class_subunion[GENERAL_REGS][VFP_LO_REGS]. But fixing it is > not a task for GCC-5.0 as we are at the very end of creation of a new > release. Fixing RA bugs has a big chance introducing new ones until it is > stabilized. This is a situation what we actually see now. So, could we perhaps just comment out the lra_assert for GCC 5.1 release, then when stage1 reopens test the other order and if it works everywhere, after a few weeks backport that to the branch? Not that it is very important, because the release will be --enable-checking=release for most users and thus the assert will be ignored anyway. Just commenting out the assert means that no further testing is needed on it right now, the patch would be obvious...