public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-65729-4-e8qBj0j6LJ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-65729-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729 Vladimir Makarov <vmakarov at gcc dot gnu.org> 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 <vmakarov at gcc dot gnu.org> --- (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.
next prev parent reply other threads:[~2015-04-10 16:13 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) " doko at gcc dot gnu.org 2015-04-10 7:07 ` [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) " jakub at gcc dot gnu.org 2015-04-10 7:47 ` rguenth at gcc dot gnu.org 2015-04-10 9:04 ` jakub at gcc dot gnu.org 2015-04-10 9:20 ` ktkachov at gcc dot gnu.org 2015-04-10 15:49 ` vmakarov at gcc dot gnu.org 2015-04-10 15:53 ` jakub at gcc dot gnu.org 2015-04-10 16:03 ` yroux at gcc dot gnu.org 2015-04-10 16:06 ` vmakarov at gcc dot gnu.org 2015-04-10 16:08 ` [Bug target/65729] [5/6 " jakub at gcc dot gnu.org 2015-04-10 16:13 ` vmakarov at gcc dot gnu.org [this message] 2015-04-10 16:43 ` jakub at gcc dot gnu.org 2015-04-15 13:07 ` yroux at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-65729-4-e8qBj0j6LJ@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).