On 01/31/15 17:47, Joseph Myers wrote:
On Fri, 30 Jan 2015, Jeff Law wrote:
+/* If we are testing a single bit resulting from a binary
+ operation in precision P1 where the operands were widened
+ precision P2 and the tested bit is the sign bit for
+ precision P2. Rewrite so the binary operation is in
+ precision P2. */
To avoid introducing undefined behavior, if the operation is arithmetic
rather than bitwise and the original type with precision P2 is signed then
you need to convert the operands to the corresponding unsigned type.
Yea, probably so.
(I'm not sure how you avoid needing to convert the final result back to
the original type of the expression to avoid type mismatches in the
containing expression, but such a conversion back to the original type
would need to be a zero-extension not a sign-extension and so for that I'd
suppose the inner type should be unsigned even for bitwise operations.
So I think the way to go to solve both issues is to wrap the result
inside a convert. Right now by working on generic, we're relying on
implicit type conversions, which feels wrong.
The nice thing about wrapping the result inside a convert is the types
for the inner operations will propagate from the type of the inner
operands, which is exactly what we want. We then remove the hack
assigning type and instead the original type will be used for the
outermost convert.
That seems to DTRT in some initial sniff testing.
And FWIW, there's no reason to restrict the pattern to just masking off
the sign bit. That's what the PR complains about, but we can do
considerably better here. That's part of the reason why I put in the
iterators -- to generalize this to more cases.
jeff
