From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-409962-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 42692 invoked by alias); 12 Oct 2015 23:03:55 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 42682 invoked by uid 89); 12 Oct 2015 23:03:54 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: resqmta-po-05v.sys.comcast.net
Received: from resqmta-po-05v.sys.comcast.net (HELO resqmta-po-05v.sys.comcast.net) (96.114.154.164) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 12 Oct 2015 23:03:53 +0000
Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242])	by resqmta-po-05v.sys.comcast.net with comcast	id UP2c1r0015E3ZMc01P3rFu; Mon, 12 Oct 2015 23:03:51 +0000
Received: from [IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d] ([IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d])	by resomta-po-18v.sys.comcast.net with comcast	id UP3o1r00E2ztT3H01P3pAo; Mon, 12 Oct 2015 23:03:50 +0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [PATCH] gcc/ira.c: Check !HAVE_FP_INSTEAD_INSNS when frame pointer is needed and as global register
From: Mike Stump <mikestump@comcast.net>
In-Reply-To: <BLU437-SMTP874BC05C13160D0903F89CB9310@phx.gbl>
Date: Mon, 12 Oct 2015 23:03:00 -0000
Cc: Bernd Schmidt <bschmidt@redhat.com>, Jeff Law <law@redhat.com>, Richard Henderson <rth@redhat.com>, "Joseph S. Myers" <joseph@codesourcery.com>, gcc-patches List <gcc-patches@gcc.gnu.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F94D964C-C840-401A-BD3A-95BFC9C83987@comcast.net>
References: <561A7D5C.40409@hotmail.com> <COL130-W507E81834CE1C264271E3BB9320@phx.gbl> <561B902A.3090609@redhat.com> <BLU437-SMTP874BC05C13160D0903F89CB9310@phx.gbl>
To: Chen Gang <xili_gchen_5257@hotmail.com>
X-IsSubscribed: yes
X-SW-Source: 2015-10/txt/msg01183.txt.bz2

On Oct 12, 2015, at 3:32 PM, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>=20
> OK, thanks. If we really need to fix it, which target hook should I use?
> (or do we need a new target hook?)

So, the first discussion would be if it is, or is not a bug.  If it isn=92t=
, then there is no fix.  No fix, no target hook.  So far, Bernd said not a =
bug.

So, I=92ll note that one _can_ do this with the stack pointer, as a fixed r=
egister.
When the frame pointer is fixed, one cannot do this.

The code that does this is:

  /* Diagnose uses of the hard frame pointer when it is used as a global=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
     register.  Often we can get away with letting the user appropriate=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
     the frame pointer, but we should let them know when code generation=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
     makes that impossible.  */
  if (global_regs[HARD_FRAME_POINTER_REGNUM] && frame_pointer_needed)
    {
      tree decl =3D global_regs_decl[HARD_FRAME_POINTER_REGNUM];
      error_at (DECL_SOURCE_LOCATION (current_function_decl),
                "frame pointer required, but reserved");
      inform (DECL_SOURCE_LOCATION (decl), "for %qD", decl);
    }

to `fix it=92, one would simple remove this chunk as misguided and fix up a=
ny code gen issues exposed.