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