From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18023 invoked by alias); 10 Apr 2015 16:13:39 -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 17945 invoked by uid 48); 10 Apr 2015 16:13:35 -0000 From: "vmakarov 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 16:13: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: vmakarov 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: priority target_milestone short_desc 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/msg00872.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729 Vladimir Makarov changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P1 Target Milestone|6.0 |5.0 Summary|[5/6 Regression] ICE (in |[5 Regression] ICE (in |prohibited_class_reg_set_mo |prohibited_class_reg_set_mo |de_p, at lra-constraints.c) |de_p, at lra-constraints.c) |on arm-linux-gnueabihf |on arm-linux-gnueabihf --- Comment #10 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #6) > (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... OK. I'll do it. As I understand (In reply to Yvan Roux from comment #7) > k, my validation is ok. I'll be off during ~3h and will submit it when I'm > back (or the assertion commenting patch) if it's better for 5.1 I've just commented the assert. We will fix it for 5.1. So, Jakub, I did what you asked as it is important for your work on release candidate. Although I'd like to work on PR65710 but I am not sure it will be fixed soon as it is a performance bug now and will take at least a few days to fix it. So the PR65710 is also work for 5.1.