On Thu, 1 Sep 2022, Richard Biener wrote:
It's generally poorly documented what is considered 'undefined behavior'.
We desparately need a section in the internals manual for this.
For the {L,R}SHIFT_EXPR case we assume the shift operand is
in range of [0, precision - 1], so in theory value-range propagation could
infer that b_8(D) < 32 after it "executed". But it seems that
range-on-exit doesn't do that yet.
[...]
The problem with shifts is that there's not a "do it anway, but without
undefined behavior" operation to substitute.
I read this as I should not report these as bugs for now. But I'll
probably keep this as UB in my tool to get an idea of how often this
happens...
Calling f(-3, 0x75181005) makes slsr_9 overflow in the optimized code,
even though the original did not overflow. My understanding is that signed
overflow invokes undefined behavior in GIMPLE, so this is a bug in
ifcombine. Is my understanding correct?
Yes, the above would be a bug - again value-range propagation might be
leveraged to produce a wrong-code testcase.
OK. I'll open bugs for the signed overflow issues the tool finds.
I would appreciate some comments on which non-memory-related operations I
should treat as invoking undefined behavior (memory operations are more
complicated, and I'll be back with more concrete questions later...).
The more "interesting" cases are uninitialized values (registers or memory).
Yes, this is the next thing I was planning to implement. :)
In general what we should worry about most is introducing undefined
behavior that, when a later pass can assume it doesn't happen, causes
wrong code to be generated. Likewise when we have late instrumentation
that would flag such undefined behavior as a user error.
Agreed. But that comes back to the issue of lacking documentation... :(
/Krister
