https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126415
--- Comment #5 from ptomsich at gcc dot gnu.org --- > I'll note that this must be an error in the pattern conditions, that it > "misfires" outside of VN isn't the issue. Agreed. forwprop is merely where it surfaced first; FRE reproduces the identical miscompile with forwprop disabled. The actual error is in the validity condition: the pattern rewrites the wide operation, which is fully defined for all inputs (wrapping outer type), into a narrow signed operation the program never executed. TYPE_OVERFLOW_UNDEFINED only permits assuming the absence of overflow for operations that are actually executed, so guarding the rewrite on it is exactly backwards for an operation the rewrite itself introduces. My queued fix reverts the match.pd pattern and instead handles PLUS_EXPR/MINUS_EXPR in visit_nary_op. The result (of the narrowing/widening) has to be available (as in the existing widening case, PR86554), so the no-overflow assumption is anchored to a dominating, executed statement. Only the conversion of the found value goes through vn_nary_build_or_lookup. Simplification there is fine since the UB argument is established at that point.
