https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
Michael Matz <matz at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matz at gcc dot gnu.org --- Comment #5 from Michael Matz <matz at gcc dot gnu.org> --- re comment #2: yeah. I don't quite see how LRA can get away (in general) without ever calling the target constraint checkers with strict_p == true. _This_ testcase can be made to work with a mega-hack, by making the generic RTL analyzers just swap base and index in the cases of ties in the opposite way. By that IRA selects the right classes from the beginning, LRA heeds those assignment, and it then so happens that everything turns out right. Obviously, as soon as the operands would be swapped then formerly working testcases would then start to fail with the hack, so it's not a solution: diff --git a/gcc/rtlanal.cc b/gcc/rtlanal.cc index 4158a531bdd..514742d1cae 100644 --- a/gcc/rtlanal.cc +++ b/gcc/rtlanal.cc @@ -6727,7 +6727,7 @@ decompose_normal_address (struct address_info *info) /* In the event of a tie, assume the base comes first. */ if (baseness (*inner_ops[0], info->mode, info->as, PLUS, GET_CODE (*ops[1])) - >= baseness (*inner_ops[1], info->mode, info->as, PLUS, + > baseness (*inner_ops[1], info->mode, info->as, PLUS, GET_CODE (*ops[0]))) { set_address_base (info, ops[0], inner_ops[0]);