combine_simplify_rtx (doesn't) commute XOR and ASHIFTRT ???

[Alan Lawrence]

Thanks for the quick response - the possibility of different modes seems
plausible, as I'm not sure what would happen in that case. (Although I'm not
entirely sure how that case would occur - something that may have changed since
the original.) I haven't had much luck in getting a working toolchain from 2004,
so I've gone with the approach of preserving the check if result_mode !=
shift_mode, as per patch https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02426.html .

Thanks!
--Alan

Richard Kenner wrote:
>>> and wondering if anyone can explain to me what's wrong with this
>>> transformation. Having worked through all four cases of A and C1
>>> positive and negative, it seems to me that the extra bits 'fed in' to
>>> the most-significant end of the result are the same either way (i.e. the
>>> XOR of the sign bits of A and C1).
>> I haven't heard from Kenner in a while, but you could always try to 
>> contact him directly and see if he can recall the issue.  It was a long 
>> time ago though...
> 
> I haven't gone anywhere ...
> 
> But indeed ten years is a long time and I don't have any recollection of
> this at all. The above analysis seems right, but this isn't the sort of
> thing I'd have done if there weren't some sort of bug.  Perhaps it's only
> relevant if result_mode != shift_mode?
>