From patchwork Wed May 24 07:51:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 766361 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wXl3Y1k28z9s86 for ; Wed, 24 May 2017 17:52:07 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="mbEm8bRb"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=mNox/i/1bGuKFyQk rBvJ7+WA1Hqcv8zEk0XjkoQZatM5jqWjbT6y/KS7ypbCx+sRe1LporfNgqkJs8wK gj0oWhC6fBFWBBQl5U4G3Cys/CZsIxwFaUomj7RCom65Ag4mkQ6GDqAl0mTIkgbV c+FyvhP7qHzi1h6IqAHMzi+h6aU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=dEji6QGgPhJPxJtz7281aB ibeqg=; b=mbEm8bRbIVeTA4hROfBFfD5wgxFfmUGxh47jdVfoS3FS+4NqQovpMB Rh0Kn2ZOaL9UJN8zrn/57mDKFiwahQp/zfkztm3xWcHpT1j8AyLeEq4YeGsHr4iE e49D12xQi3KxTb4zXxVWYSgay1TlwrnfUA2xW/77+gAGfeuggZZkQ= Received: (qmail 67906 invoked by alias); 24 May 2017 07:51:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 67882 invoked by uid 89); 24 May 2017 07:51:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=135000 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 May 2017 07:51:45 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 7140A81361 for ; Wed, 24 May 2017 09:51:47 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVQk85PY3mdN for ; Wed, 24 May 2017 09:51:47 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 49ACA8134A for ; Wed, 24 May 2017 09:51:47 +0200 (CEST) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [rs6000] Fix ICE with -fstack-limit-register and large frames Date: Wed, 24 May 2017 09:51:46 +0200 Message-ID: <1944532.Kj3BqOocuy@polaris> User-Agent: KMail/4.14.10 (Linux/3.16.7-53-desktop; KDE/4.14.9; x86_64; ; ) MIME-Version: 1.0 Hi, this fixes an internal error with -fstack-limit-register and large frames: eric@polaris:~/build/gcc/powerpc-linux> gcc/xgcc -Bgcc -S stack-limit-1.c - fstack-limit-register=r2 stack-limit-1.c: In function 'foo': stack-limit-1.c:9:1: error: insn does not satisfy its constraints: } ^ (insn 21 20 22 (set (reg:SI 0 0) (plus:SI (reg:SI 0 0) (const_int 3968 [0xf80]))) "stack-limit-1.c":5 70 {*addsi3} (nil)) stack-limit-1.c:9:1: internal compiler error: in final_scan_insn, at final.c:2964 0xb40335 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/eric/svn/gcc/gcc/rtl-error.c:108 0xb4037a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/eric/svn/gcc/gcc/rtl-error.c:119 0x83f757 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) /home/eric/svn/gcc/gcc/final.c:2964 0x83feb2 final(rtx_insn*, _IO_FILE*, int) /home/eric/svn/gcc/gcc/final.c:2051 0x84076d rest_of_handle_final /home/eric/svn/gcc/gcc/final.c:4489 0x84076d execute /home/eric/svn/gcc/gcc/final.c:4562 Please submit a full bug report, Tested on PowerPC/Linux, OK for mainline? 2017-05-24 Eric Botcazou * config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Deal properly with large frames if a stack limit is used. 2017-05-24 Eric Botcazou * gcc.target/powerpc/stack-limit-1.c: New test. Index: config/rs6000/rs6000.c =================================================================== --- config/rs6000/rs6000.c (revision 248140) +++ config/rs6000/rs6000.c (working copy) @@ -28372,7 +28372,21 @@ rs6000_emit_allocate_stack (HOST_WIDE_IN && REGNO (stack_limit_rtx) > 1 && REGNO (stack_limit_rtx) <= 31) { - emit_insn (gen_add3_insn (tmp_reg, stack_limit_rtx, GEN_INT (size))); + rtx cst = GEN_INT (size); + + /* The add expander doesn't correctly handle r0. */ + if (satisfies_constraint_I (cst)) + emit_insn (gen_rtx_SET (tmp_reg, + gen_rtx_PLUS (Pmode, stack_limit_rtx, + cst))); + else + { + emit_move_insn (tmp_reg, cst); + emit_insn (gen_rtx_SET (tmp_reg, + gen_rtx_PLUS (Pmode, stack_limit_rtx, + tmp_reg))); + } + emit_insn (gen_cond_trap (LTU, stack_reg, tmp_reg, const0_rtx)); }