final_1 already sets insn_current_address for each instruction, making it possible to use some of the address functions in final.c during assembly generation. This patch also sets insn_last_address, since as the comment says, we can treat final as a shorten_branches pass that does nothing. It's then possible to use insn_current_reference_address during final as well.
This is needed for the aarch64.md definitions of far_branch to work: (set (attr "far_branch") (if_then_else (and (ge (minus (match_dup 2) (pc)) (const_int -1048576)) (lt (minus (match_dup 2) (pc)) (const_int 1048572))) (const_int 0) (const_int 1)))] This value (tested only during final) uses the difference between the INSN_ADDRESSES of operand 2 and insn_current_reference_address to calculate a conservatively-correct estimate of the branch distance. It takes into account the worst-case gap due to alignment, whereas a direct comparison of INSN_ADDRESSES would give an unreliable, optimistic result. Tested on aarch64-linux-gnu and x86_64-linux-gnu. Sameera confirms that it fixes the original bug, but there's no sharable testcase. OK to install? Richard 2018-04-09 Richard Sandiford <richard.sandif...@linaro.org> gcc/ * final.c (final_1): Set insn_last_address as well as insn_current_address. Index: gcc/final.c =================================================================== --- gcc/final.c 2018-04-09 18:40:26.887628387 +0100 +++ gcc/final.c 2018-04-09 18:40:27.033624471 +0100 @@ -2081,6 +2081,9 @@ final_1 (rtx_insn *first, FILE *file, in } else insn_current_address = INSN_ADDRESSES (INSN_UID (insn)); + /* final can be seen as an iteration of shorten_branches that + does nothing (since a fixed point has already been reached). */ + insn_last_address = insn_current_address; } dump_basic_block_info (file, insn, start_to_bb, end_to_bb,