<div dir="ltr">UBSan doesn't cover this sort of thing - MSan is the sanitizer for catching uninitialized values. (MSan is, unfortunately, a bit more finicky to use because the whole program (including the standard library) must be compiled with the feature enabled for it to work correctly - I don't have an MSan enabled environment to test whether it would've caught this bug or not)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 7, 2019 at 9:15 AM Hans Åberg <<a href="mailto:haberg-1@telia.com">haberg-1@telia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On 7 Nov 2019, at 15:24, Hans Wennborg <<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>> wrote:<br>
> <br>
> Looking at LLVM's -print-after-all shows a diff after GVN which seems<br>
> to come from this if-statement in tests/mpn/t-sqrlo.c:<br>
> <br>
>      if (pp[-1] != p_before || pp[n] != p_after<br>
>  || scratch[-1] != s_before || scratch[itch] != s_after<br>
>  || mpn_cmp (refp, pp, n) != 0)<br>
> {<br>
> <br>
> It looks like the "scratch[-1] != s_before" expression was previously<br>
> folded to false, but now it's folded to undef (and the branch ends up<br>
> going the other way). That matches the commit message from the<br>
> bisection.<br>
<br>
GMP bugs may be reported to their bug list, and the UBSan might be strengthened to capture this.<br>
<br>
<br>
</blockquote></div>