From patchwork Sat Apr 26 09:27:35 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 343061 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 E0D5C14016E for ; Sat, 26 Apr 2014 19:27:56 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=QUVhauZQJq6QbMwqM uQ04Ik7pbTZ4tSiCmwGwHw3OeyMq/7f+VPrJfLQx/v9pmdvugjoY3EIkhGnI0nbR vqyo42NAFOv3O5EAfjpHbRNwuljO1X2hXL60ogGNAIAEHrmlWkB0cnCassSYEwBq KPeI2zfcT5h54VOfRemwErhb88= 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 :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=wF04rxS/VwOCYLL3ZYFGoVW 4CcU=; b=A3e+F/y3u7e4EyXQnjSdrg4SV+kqby9OIiPls178jfnMOzgV3KNy8e9 +UIgxjXTFFiLO+Gw+spam8UGyi8B+3rtKJrCTSquZ6w3Zjivzb/ycIU5Y5ChVArQ 7SN7AFL9HsHQ1XFHQSOzDql2teSpLZxivK/9OfeqFbLu+qkx9Rn0= Received: (qmail 30011 invoked by alias); 26 Apr 2014 09:27:48 -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 29992 invoked by uid 89); 26 Apr 2014 09:27:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 26 Apr 2014 09:27:46 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1WdytZ-0001O6-TL from Tom_deVries@mentor.com ; Sat, 26 Apr 2014 02:27:41 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Apr 2014 02:27:41 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Sat, 26 Apr 2014 10:27:39 +0100 Message-ID: <535B7C07.2090802@mentor.com> Date: Sat, 26 Apr 2014 11:27:35 +0200 From: Tom de Vries User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Richard Henderson CC: GCC Patches , Uros Bizjak , Jakub Jelinek Subject: Re: [COMMITTED] Fix debug/60438 -- i686 stack vs fp operations References: <532219CD.4010506@redhat.com> In-Reply-To: <532219CD.4010506@redhat.com> On 13-03-14 21:49, Richard Henderson wrote: > (define_expand "ldexpxf3" > - [(set (match_dup 3) > - (float:XF (match_operand:SI 2 "register_operand"))) > - (parallel [(set (match_operand:XF 0 " register_operand") > - (unspec:XF [(match_operand:XF 1 "register_operand") > - (match_dup 3)] > - UNSPEC_FSCALE_FRACT)) > - (set (match_dup 4) > - (unspec:XF [(match_dup 1) (match_dup 3)] > - UNSPEC_FSCALE_EXP))])] > + [(match_operand:XF 0 "register_operand") > + (match_operand:XF 1 "register_operand") > + (match_operand:SI 2 "register_operand")] > "TARGET_USE_FANCY_MATH_387 > && flag_unsafe_math_optimizations" > { > @@ -14808,6 +14633,11 @@ > > operands[3] = gen_reg_rtx (XFmode); > operands[4] = gen_reg_rtx (XFmode); > + > + emit_insn (gen_floatsixf2 (operands[3], operands[2])); > + emit_insn (gen_fscalexf4_i387 (operands[0], operands[4], > + operands[1], operands[3])); > + DONE; > }) Richard, For a non-bootstrap x86_64 build, gcc.dg/builtins-34.c fails for me with a sigsegv. I've traced it back to this code in insn-emit.c: ... rtx gen_ldexpxf3 (rtx operand0, rtx operand1, rtx operand2) { rtx _val = 0; start_sequence (); { rtx operands[3]; operands[0] = operand0; operands[1] = operand1; operands[2] = operand2; { if (optimize_insn_for_size_p ()) FAIL; operands[3] = gen_reg_rtx (XFmode); operands[4] = gen_reg_rtx (XFmode); ... operands is declared with size 3, and operands[3,4] accesses are out of bounds. I've done a minimal build with attached patch, and reran the test-case, which passes now. OK if bootstrap succeeds? Thanks, - Tom 2014-04-26 Tom de Vries * config/i386/i386.md (define_expand "ldexpxf3"): Fix out-of-bounds array accesses. --- gcc/config/i386/i386.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md index 25e2e93..9f103cf 100644 --- a/gcc/config/i386/i386.md +++ b/gcc/config/i386/i386.md @@ -14427,15 +14427,16 @@ "TARGET_USE_FANCY_MATH_387 && flag_unsafe_math_optimizations" { + rtx tmp1, tmp2; if (optimize_insn_for_size_p ()) FAIL; - operands[3] = gen_reg_rtx (XFmode); - operands[4] = gen_reg_rtx (XFmode); + tmp1 = gen_reg_rtx (XFmode); + tmp2 = gen_reg_rtx (XFmode); - emit_insn (gen_floatsixf2 (operands[3], operands[2])); - emit_insn (gen_fscalexf4_i387 (operands[0], operands[4], - operands[1], operands[3])); + emit_insn (gen_floatsixf2 (tmp1, operands[2])); + emit_insn (gen_fscalexf4_i387 (operands[0], tmp2, + operands[1], tmp1)); DONE; }) -- 1.8.3.2