From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21265 invoked by alias); 16 Mar 2015 09:38:52 -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 21225 invoked by uid 48); 16 Mar 2015 09:38:48 -0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201 Date: Mon, 16 Mar 2015 09:38:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 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: 2015-03/txt/msg01549.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 --- Comment #11 from Iain Sandoe --- Created attachment 35039 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35039&action=edit Patch for discussion OK so this is a frustrating area to debug. One can see the problem easily enough - but finding where it's introduced ... Question: Is there a reason that we don't have a constraint for DS-mode operands? Since there are so few constraint letters left, I have not attempted to add one - but curious about the reason. The patch is intended to do the following: 1. record that macho-pic indirections are always sufficiently aligned that a ds-mode offset is applicable (they reside in special sections with guaranteed alignment) - the picbase is also guaranteed to be aligned to 32b since it's a code label. - changes to config/darwin.{c,h} 2. I've added a new predicate (put it in darwin.md, for now since I'm just testing). - the predicate tries to look through the various cases to determine when a ds-mode operand is safe. 3. This is the bit that is in generic code and needs review: ISTM that the Y constraint code needs an additional check - at least for Darwin - if *only* for darwin, then I'm happy to conditionalise it on TARGET_MACHO. However, it's not obvious to me that no other target could be affected. What can happen is that the offset to the mem returns NULL_RTX (no offset) but there's actually quite a complex address expression - and that might not resolve to a sufficiently aligned object. Presently, the code just assumes that no offset means it's OK. --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -6378,11 +6378,20 @@ mem_operand_gpr (rtx op, machine_mode mode) { unsigned HOST_WIDE_INT offset; int extra; + unsigned align = MEM_ALIGN (op); rtx addr = XEXP (op, 0); - op = address_offset (addr); if (op == NULL_RTX) - return true; + { + /* No offset: + A naked reg is OK - any alignment works. */ + if (REG_P (addr)) + return true ; + /* Otherwise, we assume there will be a relocation, and we can't + guarantee it will fit unless the object referred to is sufficiently + aligned. */ + return align >= 32; + } NOTE: there are some debug changes in the patch - this is not intended for submission until point 3 is reviewed.