From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58402 invoked by alias); 13 Oct 2015 14:56:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 58009 invoked by uid 89); 13 Oct 2015 14:56:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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; Tue, 13 Oct 2015 14:56:03 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 81E60461C4; Tue, 13 Oct 2015 14:56:02 +0000 (UTC) Received: from localhost.localdomain (vpn1-7-62.ams2.redhat.com [10.36.7.62]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9DEu0lW006283; Tue, 13 Oct 2015 10:56:01 -0400 Subject: Re: [PATCH] gcc/ira.c: Check !HAVE_FP_INSTEAD_INSNS when frame pointer is needed and as global register To: Chen Gang , Mike Stump References: <561A7D5C.40409@hotmail.com> <561B902A.3090609@redhat.com> Cc: Jeff Law , Richard Henderson , "Joseph S. Myers" , gcc-patches List From: Bernd Schmidt Message-ID: <561D1B80.8050706@redhat.com> Date: Tue, 13 Oct 2015 14:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01259.txt.bz2 On 10/13/2015 04:50 PM, Chen Gang wrote: > OK, under the bugzilla, the maintainer treated it as expected behavior > (not a bug). For me, we need more explanation for it (why we treat it > as expected behavior). A global register is under control of the user. If the compiler uses it as a frame pointer, it will get clobbered outside the user's control, which is unexpected behaviour. Therefore, the code Mike quoted detects that case and issues an error, indicating that you must use -fomit-frame-pointer if you expect to use the frame pointer register for other purposes. If you want an address on the stack there's __builtin_frame_address which may or may not do what was intended. The code quoted in the bugzilla is just invalid. >> to `fix it’, one would simple remove this chunk as misguided and fix up any code gen issues exposed. >> > > If there were not only one issues related with it, for me, what you said > sounds reasonable to me. That's totally the wrong thing to do as the issue is not compiler code generation, it's the danger of clobbering a user variable. Bernd