https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413
--- Comment #18 from Michael Matz <matz at gcc dot gnu.org> ---
This last problem is a pre-existing one in the backend. It accepts bare
label_ref plus operands, but it does so also in flag_pic mode. There it
isn't correct (because it implies another memory reference). This problem
was masked earlier because expand generates the address reference to the
jump table with a ASHIFT, which wasn't accepted formerly by the backend.
That non-acceptance lead to expand decomposing everything in the address
to registers, including the bare label_ref, which then ultimately went the
correct ways.
The LRA patches now _do_ accept the ASHIFT parts (and that's okay), but this
leads to an overall acceptance of '(plus (ashift (reg) (1)) (label_ref))'
and that's not acceptable (ahem). Solution: don't accept a bare label_ref
as plus operand if flag_pic. See below:
@@ -2247,6 +2275,7 @@ m68k_decompose_address (machine_mode mode, rtx x,
references. It seems unlikely that we would ever generate indexed
accesses to unplaced labels in other cases. */
if (GET_CODE (x) == PLUS
+ && !flag_pic
&& m68k_jump_table_ref_p (XEXP (x, 1))
&& m68k_decompose_index (XEXP (x, 0), strict_p, address))
{
