This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Possible issue with using LAST_INSN_CODE
- From: Claudiu Zissulescu <claziss at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Francois Bedard <Francois dot Bedard at synopsys dot com>, Richard Sandiford <richard dot sandiford at arm dot com>
- Date: Thu, 20 Aug 2015 19:28:10 +0200
- Subject: Re: Possible issue with using LAST_INSN_CODE
- Authentication-results: sourceware.org; auth=none
- References: <098ECE41A0A6114BB2A07F1EC238DE8965C6756D at de02wembxa dot internal dot synopsys dot com> <55D6064F dot 40505 at redhat dot com>
Hi Jeff,
In the gencodes.c:89, it explicitly decrements by one the return
value of get_num_insn_codes(). While for the get_num_insn_codes is
stated this:
/* Return the number of possible INSN_CODEs. Only meaningful once the
whole file has been processed. */
I can provide an example for the ARC port where it crashes due to
LAST_INSN_CODE issue. Probably it can be reproduced with other more
popular port like ARM.
//Claudiu
On Thu, Aug 20, 2015 at 6:54 PM, Jeff Law <law@redhat.com> wrote:
> On 08/20/2015 02:54 AM, Claudiu Zissulescu wrote:
>>
>> Hi,
>>
>> The LAST_INSN_CODE is used to mark the last instruction code valid
>> for a particular architecture (e.g., For ARM the value of
>> LAST_INSN_CODE is 3799). Also this code (i.e., 3799) is used by a
>> predicated instruction (e.g., for ARM this code is used by predicated
>> version of arm_usatsihi => {*p arm_usatsihi}).
>>
>> However, the LAST_INSN_CODE macro is used by lra, recog and
>> tree-vect-stmts to dimension various arrays which may lead to various
>> errors.
>>
>> For example, when calling preprocess_insn_constraints (recog.c:2444),
>> the compilation may go berserk when evaluating "if
>> (this_target_recog->x_op_alt[icode])" line when icode is exactly the
>> LAST_INSN_CODE as "this_target_recog->x_op_alt" is dimensioned up to
>> LAST_INSN_CODE (recog.h:397).
>>
>> A possible solution is having the LAST_INSN_CODE value to be exactly
>> the value returned by get_num_isns_codes() (gencodes.c:89).
>> Alternatively is to use LAST_INSN_CODE+1 when defining an array.
>>
>> Please can someone confirm my observation. And what will be the best
>> solution for this.
>
> It seems to me like something has been broken then.
>
> LAST_INSN_CODE is supposed to be higher than any insn defined by the
> backend.
>
>
> Jeff