[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

["dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Confirmed.  The problem occurs in fwprop1 where instructions corresponding to the
> following assembly
>	addis r2,r31,ha16(_A.1.1600-L1$pb)
>	la r9,lo16(_A.1.1600-L1$pb)(r2)
>	ld r2,0(r9)
> are combined to
>	addis r2,r31,ha16(_A.1.1600-L1$pb)
>	la r9,lo16(_A.1.1600-L1$pb)(r2)
>	ld r2,lo16(_A.1.1600-L1$pb)(r2)
> ie. the offset is propagated into the memory load.  This ought to give you
> an error at assembly or link time.

No error at assembly or link time.

> If not, you have a bad assembler or linker..

Well, we'll have to live with them!-(EOL target).

> movdi_low is the culprit, I think.  It should require a suitably aligned
> offset (operand 2).

How?
>From gcc-bugs-return-479647-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 07 14:46:06 2015
Return-Path: <gcc-bugs-return-479647-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 35719 invoked by alias); 7 Mar 2015 14:46:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 35677 invoked by uid 48); 7 Mar 2015 14:46:02 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65343] unexpected exception thrown during destruction of static object in debug mode
Date: Sat, 07 Mar 2015 14:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65343-4-m6JUryoRLQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65343-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65343-4@http.gcc.gnu.org/bugzilla/>
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/msg00791.txt.bz2
Content-length: 398

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide343

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Maybe we want to placement-new the mutexes into a buffer so they are never
destroyed, although on mingw that will show up as leaked resources at program
shutdown (and this is only really a problem on mingw as we don't need to run
any destructor on the mutexes for most targets).