From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128616 invoked by alias); 26 Feb 2015 11:45:49 -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 128574 invoked by uid 48); 26 Feb 2015 11:45:46 -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:46: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/msg02910.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65215 --- Comment #10 from Richard Biener --- (In reply to Richard Biener from comment #9) > (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!?) And what I changed was Index: tree-ssa-math-opts.c =================================================================== --- tree-ssa-math-opts.c (revision 212067) +++ tree-ssa-math-opts.c (revision 212068) @@ -2179,7 +2179,9 @@ bswap_replace (gimple cur_stmt, gimple_s unsigned align; align = get_object_alignment (src); - if (bswap && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) + if (bswap + && align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) + && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) return false; gsi_move_before (&gsi, &gsi_ins); > > > > 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