This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Possible issue with using LAST_INSN_CODE


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]