On Montag, 11. März 2019 10:14:49 CET Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 08:49:30AM +0000, Moritz Strübe wrote:
> > Considering that C11 6.5.7#3 ("If the value of the right operand
> > is negative or is greater than or equal to the width of the promoted
> > left operand, the behavior is undefined.") is not very widely known, as
> > it "normally" just works, inverting the intent is quite unexpected.
> >
> > Is there any option that would have helped me with this?
>
> You could build with -fsanitize=undefined, that would tell you at runtime
> you have undefined behavior in your code (if the SingleDiff has bit ever
> 0x20 set).
>
> The fact that negative or >= bit precision shifts are UB is widely known,
> and even if it wouldn't, for the compiler all the UBs are just UBs, the
> compiler optimizes on the assumption that UB does not happen, so when it
> sees 32-bit int << (x & 32), it can assume x must be 0 at that point,
> anything else is UB.
>
Hmm, I am curious. How strongly would gcc assume x is 0?
What if you have some expression that is undefined if x is not zero, but x
really isn't zero and the result is temporarily undefined, but then another
statement or part of the expression fixes the final result to something
defined regardless of the intermediate. Would the compiler make assumptions
that the intermediate value is never undefined, and possibly carry that
analysed information over into other expressions?
>From having fixed UBSAN warnings, I have seen many cases where undefined
behavior was performed, but where the code was aware of it and the final
result of the expression was well defined nonetheless.
'Allan
