From patchwork Sun Mar 23 12:02:41 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 332883 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 D11B02C0084 for ; Sun, 23 Mar 2014 23:04:09 +1100 (EST) 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=AyEd/4likVBpc8DR fyY7wtF+wROJf/IhYPzPYTTLEBjvXQ6VXcJdcZWXEZHMUWYA+cIPUPzZwM+7+ocf rysU2VsSgckR5smt8AV9LIWRQXA84rfUeTs5KwMTMnH4YXTaBDX4rwdVl/GCfJwC Y3Vap5vCcPUBKPSkPGAnPMufqfs= 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=Li3wDLqfGUO41316beqpjs 6tZXA=; b=g7JgBqVCdgx5Aq4iCMU3y7mjg9Ks0793avvMhqUvRL3QqTA9n+n8Zm X9W42mMXKPLMfoh4O43+MvMQIJ0I8LsIaaWyF2eO6FG9EIaxUjJIQJ+ux3GPJihJ Zi0CbhJ4iK7BzGyvtXMimdSlTtMCivCU39Ph8RLmcL3Zsn9gTHbAo= Received: (qmail 18674 invoked by alias); 23 Mar 2014 12:03:59 -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 18663 invoked by uid 89); 23 Mar 2014 12:03:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 23 Mar 2014 12:03:55 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 1E0882709DA2 for ; Sun, 23 Mar 2014 13:03:53 +0100 (CET) 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 iwcHE9NmB6gB for ; Sun, 23 Mar 2014 13:03:53 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id EAD192709D65 for ; Sun, 23 Mar 2014 13:03:52 +0100 (CET) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: Fix PR rtl-optimization/60452 Date: Sun, 23 Mar 2014 13:02:41 +0100 Message-ID: <41050782.FO0TJjpIUH@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.29-desktop; KDE/4.7.2; x86_64; ; ) MIME-Version: 1.0 This is a regression present on mainline and 4.8 branch: ifcvt generates a conditional move from an invalid location on the stack, resulting in a segfault at runtime. The testcase is pathological and exploits the very old RTL semantics (now embodied in may_trap_or_fault_p) of considering that stack references cannot trap, which is of course wrong for nonsensical offsets. This is an old issue (the attached testcase distilled by Jakub already fails with GCC 4.3) and the original testcase is clearly machine-generated, so I don't think that we need to pessimize the common case for it; instead fixing this kind of very minor issues on a case-by-case basis is good enough I think. The attached patch only adds a check in rtx_addr_can_trap_p_1 for nonsensical offsets against the frame pointer; this is sufficient for both testcases. The check is supposed to be exact (e.g. it never triggers during a bootstrap) so it won't pessimize anything. This might be different if the ??? comment is addressed later but, again, I don't think that we should care at this point. Tested on x86_64-suse-linux, any objections? 2014-03-23 Eric Botcazou PR rtl-optimization/60452 * rtlanal.c (rtx_addr_can_trap_p_1): Fix head comment. : Return 1 for nonsensical offsets from the frame pointer. 2014-03-23 Eric Botcazou * gcc.c-torture/execute/20140323-1.c: New test. Index: rtlanal.c =================================================================== --- rtlanal.c (revision 208763) +++ rtlanal.c (working copy) @@ -224,10 +224,10 @@ rtx_varies_p (const_rtx x, bool for_alia return 0; } -/* Return nonzero if the use of X as an address in a MEM can cause a trap. - MODE is the mode of the MEM (not that of X) and UNALIGNED_MEMS controls - whether nonzero is returned for unaligned memory accesses on strict - alignment machines. */ +/* Return nonzero if the use of X+OFFSET as an address in a MEM with SIZE + bytes can cause a trap. MODE is the mode of the MEM (not that of X) and + UNALIGNED_MEMS controls whether nonzero is returned for unaligned memory + references on strict alignment machines. */ static int rtx_addr_can_trap_p_1 (const_rtx x, HOST_WIDE_INT offset, HOST_WIDE_INT size, @@ -235,11 +235,12 @@ rtx_addr_can_trap_p_1 (const_rtx x, HOST { enum rtx_code code = GET_CODE (x); - if (STRICT_ALIGNMENT - && unaligned_mems - && GET_MODE_SIZE (mode) != 0) + /* The offset must be a multiple of the mode size if we are considering + unaligned memory references on strict alignment machines. */ + if (STRICT_ALIGNMENT && unaligned_mems && GET_MODE_SIZE (mode) != 0) { HOST_WIDE_INT actual_offset = offset; + #ifdef SPARC_STACK_BOUNDARY_HACK /* ??? The SPARC port may claim a STACK_BOUNDARY higher than the real alignment of %sp. However, when it does this, the @@ -298,8 +299,27 @@ rtx_addr_can_trap_p_1 (const_rtx x, HOST return 0; case REG: - /* As in rtx_varies_p, we have to use the actual rtx, not reg number. */ - if (x == frame_pointer_rtx || x == hard_frame_pointer_rtx + /* Stack references are assumed not to trap, but we need to deal with + nonsensical offsets. */ + if (x == frame_pointer_rtx) + { + HOST_WIDE_INT adj_offset = offset - STARTING_FRAME_OFFSET; + if (size == 0) + size = GET_MODE_SIZE (mode); + if (FRAME_GROWS_DOWNWARD) + { + if (adj_offset < frame_offset || adj_offset + size - 1 >= 0) + return 1; + } + else + { + if (adj_offset < 0 || adj_offset + size - 1 >= frame_offset) + return 1; + } + return 0; + } + /* ??? Need to add a similar guard for nonsensical offsets. */ + if (x == hard_frame_pointer_rtx || x == stack_pointer_rtx /* The arg pointer varies if it is not a fixed register. */ || (x == arg_pointer_rtx && fixed_regs[ARG_POINTER_REGNUM])) @@ -320,9 +340,7 @@ rtx_addr_can_trap_p_1 (const_rtx x, HOST if (XEXP (x, 0) == pic_offset_table_rtx && CONSTANT_P (XEXP (x, 1))) return 0; - /* - or it is an address that can't trap plus a constant integer, - with the proper remainder modulo the mode size if we are - considering unaligned memory references. */ + /* - or it is an address that can't trap plus a constant integer. */ if (CONST_INT_P (XEXP (x, 1)) && !rtx_addr_can_trap_p_1 (XEXP (x, 0), offset + INTVAL (XEXP (x, 1)), size, mode, unaligned_mems))