From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24196 invoked by alias); 5 Nov 2013 09:41:04 -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 21477 invoked by uid 48); 5 Nov 2013 09:39:02 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/58997] ICE on valid code at -O3 on x86_64-linux-gnu (affecting gcc trunk and 4.8.2) Date: Tue, 05 Nov 2013 09:41: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-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc assigned_to everconfirmed attachments.created 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: 2013-11/txt/msg00309.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58997 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2013-11-05 CC| |jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 31158 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31158&action=edit gcc49-pr58997.patch Untested fix. Likely regressed in r110005. For IV_UNKNOWN_EXTEND, get_iv_value returns value in iv->mode rather than iv->extend_mode, so for iv_subreg we just need to adjust the last argument to lowpart_subreg. For iv_extend similarly, but IMHO (no testcase) if iv->extend is not unknown, but different from currently required extend, then the code misbehaves too, say for iv->extend IV_SIGN_EXTEND what get_iv_value returns is say HImode sign extended into SImode, if we do iv_extend IV_ZERO_EXTEND to say DImode on this, then it would give us for negative HImode a value with bits 16-31 all set rather than clear. And, additionally (again, no testcase), the uses in may_unswitch_on I can't see how we couldn't end up with get_iv_value returning there zero resp. sign extended op[i], i.e. wider than we want. If the other IV isn't sign/zero extended, or is extended to different mode or differently, or if the other operand is constant (which should be sign extended from the mode), I'd say this can create invalid RTL or wrong-code.