From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105901 invoked by alias); 3 Mar 2015 22:27:25 -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 105858 invoked by uid 48); 3 Mar 2015 22:27:21 -0000 From: "meissner at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu Date: Tue, 03 Mar 2015 22:27: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: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: meissner at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned 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-03/txt/msg00402.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65240 --- Comment #9 from Michael Meissner --- It is likely due to a combination of -ffast-math and -mupper-regs on power7/power8. This is a problem I've seen before, but I thought I had squashed it. Basically, the code I've seen before, you have code that uses enough registers that it wants to allocate registers using the traditional Altivec registers, and you load up some constants. If you don't use -ffast-math, then everything is fine, because the constant is pushed to the constant pool before register allocation begins. However, due to wanting the constant around so that reciprocal math can be done (i.e. -ffast-math), the constant is kept around until register allocation time. During register allocation time, we allocate a FPR for the constant because it wants to use d-form addressing (reg+offset). However, one of the post reload passes (usually gcse-after-reload) goes in and decides to change the load from loading up a FPR register to loading it directly to an Altivec register and fails because we don't have d-form addressing for Altivec registers. The usual case is reload loads up a FPR and then does a move to the Atlivec register, and that gets combined. I think I've see it also happen, where you are loading the same constant twice, and GCSE decides to use the Altivec version. I'll try to look at it tomorrow.