This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v3] PR48344: Fix unrecognizable insn error with -fstack-limit-register=r2
- From: Kelvin Nilsen <kdnilsen at linux dot vnet dot ibm dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Fri, 5 Feb 2016 15:00:46 -0700
- Subject: Re: [PATCH v3] PR48344: Fix unrecognizable insn error with -fstack-limit-register=r2
- Authentication-results: sourceware.org; auth=none
- References: <56B519C8 dot 9080904 at linux dot vnet dot ibm dot com>
Ping. Thanks.
On 01/27/2016 11:12 AM, Kelvin Nilsen wrote:
This patch has bootstrapped and tested on
powerpc64le-unknown-linux-gnu with no regressions. Is this ok for the
trunk?
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48344 for the
original problem report. The error resulted because gcc's processing
of command-line options within gcc initialization code originally
preceded the processing of target-specific configuration hooks.
In the unpatched gcc implementation, the Pmode (pointer mode) variable
has not been initialized at the time the -fstack-limit-register
command-line option is processed. As a consequence, the
stack-limiting register is not assigned a proper mode. Thus, rtl
instructions that make use of this stack-limiting register have an
unspecified mode, and are therefore not matched by any known
instructions.
The fix represented in this patch is to defer the command-line
processing related to command-line specification of a stack-limiting
register until after target-specific initialization has been completed.
Some questions and issues raised in response to version 2 of this
patch are addressed below:
1. Concerns regarding possible unintended consequences that might
result from moving all target-specific initialization to precede the
invocation of the handle_common_deferred_options () function are
addressed by preserving the original initialization order and moving
the relevant command-line processing to follow the target-specific
initialization.
2. A question was raised as to whether Pmode can change with attribute
target. It cannot.
Here is the original message:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02146.html