From patchwork Fri Mar 4 13:44:33 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 592050 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 2C056140273 for ; Sat, 5 Mar 2016 00:44:44 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=TZOL/ort; 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:cc:subject:date:message-id:mime-version:content-type; q=dns; s=default; b=YVAupDCWhARFMMde+20RyqzsRIP5BG54LKv5PrCNZkN6Ho9goV 9J7iTFbuIChY5BH1H978Oz1Szupk1zGXhxPzB9M5wwI6wfE5iQFO0DwXfEWFBxs0 xyTCmwTalo6jOtzFbR87g30GrsowKGZJ+yE5J2s+HMpEHF+7mDKp/ZhrQ= 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:cc:subject:date:message-id:mime-version:content-type; s= default; bh=2IZv/tBec5rkcsqsub3pKqPbOEQ=; b=TZOL/ort0gp7crpccjBr fOm28e1DoiAdNtLNXpIcltxwSUKNALZW7zfTtr9Jhrij/CsMk5X5XCY+wcqwK+TB +kfV/e3kmtlgdsZJ7/mxQZNNnnjhA7sFgSImBwsrtDj5P8Qj8O3x3f7d7z6MO/DC rkiGPOHcnEZTY5Yx1TrvLZ4= Received: (qmail 108098 invoked by alias); 4 Mar 2016 13:44:38 -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 108088 invoked by uid 89); 4 Mar 2016 13:44:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Catch X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 04 Mar 2016 13:44:36 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9077E7AE83; Fri, 4 Mar 2016 13:44:35 +0000 (UTC) Received: from littlehelper.redhat.com (vpn1-4-205.ams2.redhat.com [10.36.4.205]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u24DiXKL022247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Mar 2016 08:44:34 -0500 From: Nick Clifton To: marcus.shawcroft@arm.com, richard.earnshaw@arm.com Cc: gcc-patches@gcc.gnu.org Subject: RFA: PR 70044: Catch a second call to aarch64_override_options_after_change Date: Fri, 04 Mar 2016 13:44:33 +0000 Message-ID: <87a8metl1a.fsf@redhat.com> MIME-Version: 1.0 X-IsSubscribed: yes Hi Markus, Hi Richard, PR 70044 reports a problem with the AArch64 backend. With LTO enabled the function aarch64_override_options_after_change can be called more than once for the same function. If only leaf frame pointers were being omitted originally, then the first call will set flag_omit_frame_pointer to true. Then the second call will set flag_omit_leaf_frame_pointer to false, thus forcing the frame pointer to always be omitted, contrary to the original settings of these flags. The attached patch fixes this problem by setting flag_omit_frame_pointer to true, but using a special value of 2 to do so. Then when the second call occurs we can detect this case and ensure that we do not set flag_omit_leaf_frame_pointer to false. Tested with no regressions on an aarch64-elf toolchain. OK to apply ? Cheers Nick gcc/ChangeLog 2016-03-04 Nick Clifton PR target/7044 * config/aarch64/aarch64.c (aarch64_override_options_after_change_1): When forcing flag_omit_frame_pointer to be true, use a special value that can be detected if this function is called again, thus preventing flag_omit_leaf_frame_pointer from being forced to be false. Index: gcc/config/aarch64/aarch64.c =================================================================== --- gcc/config/aarch64/aarch64.c (revision 233960) +++ gcc/config/aarch64/aarch64.c (working copy) @@ -8110,6 +8110,21 @@ static void aarch64_override_options_after_change_1 (struct gcc_options *opts) { + /* The logic here is that if we are disabling all frame pointer generation + then we do not need to disable leaf frame pointer generation as a + separate operation. But if we are *only* disabling leaf frame pointer + generation then we set flag_omit_frame_pointer to true, but in + aarch64_frame_pointer_required we return false only for leaf functions. + + PR 70044: We have to be careful about being called multiple times for the + same function. Once we have decided to set flag_omit_frame_pointer just + so that we can omit leaf frame pointers, we must then not interpret a + second call as meaning that all frame pointer generation should be + omitted. We do this by setting flag_omit_frame_pointer to a special, + non-zero value. */ + if (opts->x_flag_omit_frame_pointer == 2) + opts->x_flag_omit_frame_pointer = 0; + if (opts->x_flag_omit_frame_pointer) opts->x_flag_omit_leaf_frame_pointer = false; else if (opts->x_flag_omit_leaf_frame_pointer)