From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2363 invoked by alias); 2 Sep 2013 23:35:27 -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 2300 invoked by uid 48); 2 Sep 2013 23:35:23 -0000 From: "bernd.edlinger at hotmail dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array Date: Mon, 02 Sep 2013 23:35: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-Version: 4.8.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: bernd.edlinger at hotmail dot de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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-09/txt/msg00097.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #24 from Bernd Edlinger --- Created attachment 30743 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30743&action=edit Yet another untested fix Ok, this is somewhat similar to Martin's very first attempt to fix this. After staring at the code for quite a long time, I believe the misalign code path is meant for structures or unions that can be accessed in a mode != BLKmode which is the mode of the largest member of a union for instance. But if that mode has a movmisalign op that should be used. However that is only an optimization, store_field will always be able to store the value byte by byte if necessary. If offset != 0 we have a non-constant (or maybe negative) array index here. If volatile we have a volatile access. If bitpos + bitsize > GET_MODE_BITSIZE we probably have an array with a constant index. If any of these happens, better not go the misalign code path. The second hunk is necessary because the if block sets bitpos = 0, but leaves bitregion_start and bitregion_end untouched, creating an inconsistent bitregion, which may or may not assert later. Therefore check that this is no bitregion. If it is a bit region store_field can handle it. How do you like this patch?