From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32309 invoked by alias); 19 Nov 2011 18:39:32 -0000 Received: (qmail 32298 invoked by uid 22791); 19 Nov 2011 18:39:31 -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; Sat, 19 Nov 2011 18:39:19 +0000 From: "ebotcazou at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691 Date: Sat, 19 Nov 2011 19:29: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: X-Bugzilla-Severity: normal X-Bugzilla-Who: ebotcazou at gcc dot gnu.org X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 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: 2011-11/txt/msg02000.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Eric Botcazou changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ebotcazou at gcc dot | |gnu.org --- Comment #17 from Eric Botcazou 2011-11-19 18:38:48 UTC --- > we are talking about bit fields - i.e contiguous blocks of bits - so, if memory > serves me correctly, we are not in the realm of padding rules (but I need to > double-check the ABI doc). > > so: > > When BIG-Endian && !BLKMode ... you are copying the data in reverse order > (pushing the bitfield into the least significant bits of the destination) - > ergo the remaining fragment needs to be stored at the "higher" sub-address of > the fragmented last word. > > When BE && BLKmode you are copying in ascending address order (i.e. aligning > the bits to the MS) .. ergo the remaining fragment needs to be copied to the > "lower" sub-address of the last fragmented word. In any case, the new code probably needs to be coordinated with this: /* Here we transfer the words of the field in the order least significant first. This is because the most significant word is the one which may be less than full. However, only do that if the value is not BLKmode. */ unsigned int backwards = WORDS_BIG_ENDIAN && fieldmode != BLKmode;