From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 785 invoked by alias); 19 Jan 2012 07:33:51 -0000 Received: (qmail 771 invoked by uid 22791); 19 Jan 2012 07:33:50 -0000 X-SWARE-Spam-Status: No, hits=-2.9 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; Thu, 19 Jan 2012 07:33:37 +0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg Date: Thu, 19 Jan 2012 08:19:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC 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 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: 2012-01/txt/msg02079.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jamborm at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2012-01-19 07:33:07 UTC --- This starts with eipa_sra. It changes a S argument (which has TImode TYPE_MODE) into char [9] (with BLKmode)) and then on both caller and callee side we have on one side a BLKmode type and on the other side a BLKmode MEM_REF with pointer to TImode on the second MEM_REF operand. I wonder why it does this, instead of just using type S, and if it really has to for some reason, why it can't at least make sure it has the same TYPE_MODE. Changing a TImode argument to a BLKmode argument doesn't look at least like a good optimization. Or the bug is in the MEM_REF expansion, which expands a BLKmode MEM_REF into a TImode reg: bftype = TREE_TYPE (base); if (TYPE_MODE (TREE_TYPE (exp)) != BLKmode) bftype = TREE_TYPE (exp); return expand_expr (build3 (BIT_FIELD_REF, bftype, base, TYPE_SIZE (TREE_TYPE (exp)), bit_offset), target, tmode, modifier); base here is TImode (x PARM_DECL), but exp is BLKmode, so this returns a TImode pseudo. Shouldn't it store it into a BLKmode temporary and return that MEM instead?