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: PR 18294: help with rtl-optimization bug on IA64


Steve Ellcey wrote:
I was wondering if anyone could offer some advice on PR 18294.  It
breaks the IA64 HP-UX bootstrap and I cut the problem down to a
small test case (see the defect report) and then tracked the problem
down to the code that is inside the POINTERS_EXTEND_UNSIGNED ifdef in
instantiate_virtual_regs_1 (function.c).

Put a breakpoint in make_insn_raw, make it conditional on the instruction number (91 in your case), then look at the call stack, and we see that the problem is the gen_lowpart call. This may create new RTL, and does in this case. New RTL is put at the current insertion point, which normally is the end of the function. This can be changed by emitting the RTL into a sequence, but there is no sequence here to hold the RTL.


There is also a related problem, if the validate_change call fails, then we have to delete the new RTL created by gen_lowpart, but there is no code for this. Again, this can be fixed by using a sequence.

New RTL is created in this case because simplify_subreg refuses to create a subreg of the frame pointer. The comments say return without doing anything, to leave the subreg as a subreg. However, we are calling simplify_subreg from simplify_gen_subreg, and simplify_gen_subreg returns NULL if the input was a hard register. This seems to be a bug in simplify_gen_subreg. If we have a special reg like ap/sp/fp, then it should go ahead and create the subreg, which is the intent here. The test in simplify_gen_subreg needs to be based on the test in simplify_subreg, to ensure that we only create the subregs when simplify_subreg wanted us to. I.e. we create them for the special regs ap/sp/fp, but not when the CANNOT_CHANGE_MODE_CLASS says we can't create the subreg. There might be a better way to structure this. If this problem is fixed, then gen_lowpart probably won't ever generate new RTL in this case anymore, and we may not have to worry about creating and using sequences here.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com



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