This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Possible issue with using LAST_INSN_CODE
- From: Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Cc: Francois Bedard <Francois dot Bedard at synopsys dot com>
- Date: Thu, 20 Aug 2015 08:54:44 +0000
- Subject: Possible issue with using LAST_INSN_CODE
- Authentication-results: sourceware.org; auth=none
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.
Thanks,
Claudiu