From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125591 invoked by alias); 26 Feb 2015 11:44:08 -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 125367 invoked by uid 48); 26 Feb 2015 11:44:04 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/65215] [5 Regression] Bswap load miscompilation Date: Thu, 26 Feb 2015 12:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: 2015-02/txt/msg02908.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65215 --- Comment #9 from Richard Biener --- (In reply to Thomas Preud'homme from comment #5) > (In reply to Richard Biener from comment #4) > > (In reply to Jakub Jelinek from comment #1) > > > Created attachment 34879 [details] > > > gcc5-pr65215.patch > > > > > > Untested fix. There are still issues left, e.g. I can't understand the > > > "bswap &&" part in > > > if (bswap > > > && align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) > > > && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) > > > return false; > > > Don't you use the new MEM_REF even for the !bswap (aka nop) case? So, I > > > don't see how it would be safe to generate that. > > > And the testsuite coverage of this is definitely suboptimal, from endianity > > > POV, bitfields etc. > > > > I suggested that change (remove bswap &&) multiple times, but it got lost > > appearantly. (I even remember applying that change myself!?) > > > I remember the contrary as this was the reason PR61320 was investigated in > the first place. This idea is that if it's unaligned the expander will take > care of this and that they would be at least as efficient as what the user > code was doing to avoid doing an unaligned load. Ah indeed. The idea is that the expander should be able to produce the most optimal and canonical form for an unaligned load on those targets, especially for say loading a 4-byte value from a 2-byte aligned source where the source had 4 individual char loads. > I'm happy to revisit that position though. No - I just stand corrected. > Best regards, > > Thomas