@@ -3195,11 +3195,15 @@ simplify_context::simplify_binary_operation_1 (rtx_code code,
canonicalize (minus A (plus B C)) to (minus (minus A B) C).
Don't use the associative law for floating point.
The inaccuracy makes it nonassociative,
- and subtle programs can break if operations are associated. */
+ and subtle programs can break if operations are associated.
+ Don't use the associative law when subtracting a MINUS from
+ a REG_POINTER as that can trick find_base_term into discovering
+ the wrong base. */
if (INTEGRAL_MODE_P (mode)
&& (plus_minus_operand_p (op0)
- || plus_minus_operand_p (op1))
+ || ((!REG_P (op0) || !REG_POINTER (op0))
+ && plus_minus_operand_p (op1)))
&& (tem = simplify_plus_minus (code, mode, op0, op1)) != 0)
return tem;
The following avoids re-associating (minus:DI (reg/f:DI 119) (minus:DI (reg/f:DI 120) (reg/f:DI 114))) into (minus:DI (plus:DI (reg/f:DI 114) (reg/f:DI 119)) (reg/f:DI 120)) as that possibly confuses the REG_POINTER heuristics of RTL alias analysis. This happens to miscompile the PRs testcase during DSE which expands addresses via CSELIB which eventually simplifies what it substituted to. The original code does the innocent ptr - (ptr2 - ptr2'), bias a pointer by the difference of two other pointers. -- This is what I propose for the PR for branches, I have not made much progress with fixing the fallout on the RTL alias analysis change on trunk, so this is the alternative if we decide to revert that. Bootstrapped and tested on x86_64-unknown-linux-gnu on the gcc-13 branch, bootstrapped after reverting of the previous fix on x86_64-unknown-linux-gnu on trunk, testing is still ongoing there. OK? Any preference for trunk? Thanks, Richard. PR rtl-optimization/113255 * simplify-rtx.cc (simplify_context::simplify_binary_operation_1): Do not re-associate a MINUS with a REG_POINTER op0. --- gcc/simplify-rtx.cc | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)