On Thu, Apr 18, 2024 at 11:25:43AM +0200, Christophe Lyon wrote:
> On Thu, 18 Apr 2024 at 09:37, Jakub Jelinek <ja...@redhat.com> wrote:
> > The following testcase aborts on aarch64-linux but does not on x86_64-linux.
> > In both cases there is UB in the __divmodbitint4 implemenetation.
> > When the divisor is negative with most significant limb (even when partial)
> > all ones, has at least 2 limbs and the second most significant limb has the
> > most significant bit clear, when this number is negated, it will have 0
> > in the most significant limb.
> > Already in the PR114397 r14-9592 fix I was dealing with such divisors, but
> > thought the problem is only if because of that un < vn doesn't imply the
> > quotient is 0 and remainder u.
> > But as this testcase shows, the problem is with such divisors always.
> > What happens is that we use __builtin_clz* on the most significant limb,
> > and assume it will not be 0 because that is UB for the builtins.
> > Normally the most significant limb of the divisor shouldn't be 0, as
> > guaranteed by the bitint_reduce_prec e.g. for the positive numbers, unless
> > the divisor is just 0 (but for vn == 1 we have special cases).
>
> Just curious: could this have been caught by ubsan? (I don't know if
> it knows about clz)
ubsan does instrument clz, I don't remember right now if even libgcc is
built with -fsanitize=undefined during bootstrap-ubsan, if it is, it
probably should (but we didn't have this test in the testsuite).
Jakub
