Looks like valgrind catches some things around here:
==115793== Conditional jump or move depends on uninitialised value(s)
==115793== at 0x402671: main (t-sqrlo.c:106)
==115793==
==115793== Conditional jump or move depends on uninitialised value(s)
==115793== at 0x40268A: main (t-sqrlo.c:107)
==115793==
On Thu, Nov 7, 2019 at 9:42 AM David Blaikie <dblai...@gmail.com> wrote:
> 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)
>
> On Thu, Nov 7, 2019 at 9:15 AM Hans Åberg <haber...@telia.com> wrote:
>
>>
>> > On 7 Nov 2019, at 15:24, Hans Wennborg <h...@chromium.org> wrote:
>> >
>> > Looking at LLVM's -print-after-all shows a diff after GVN which seems
>> > to come from this if-statement in tests/mpn/t-sqrlo.c:
>> >
>> > if (pp[-1] != p_before || pp[n] != p_after
>> > || scratch[-1] != s_before || scratch[itch] != s_after
>> > || mpn_cmp (refp, pp, n) != 0)
>> > {
>> >
>> > It looks like the "scratch[-1] != s_before" expression was previously
>> > folded to false, but now it's folded to undef (and the branch ends up
>> > going the other way). That matches the commit message from the
>> > bisection.
>>
>> GMP bugs may be reported to their bug list, and the UBSan might be
>> strengthened to capture this.
>>
>>
>>
_______________________________________________
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
