llvm dev - Apr 2018 - compiler-rt incorrect for this udivmodti4 case?

Here is my test case:

#include <stdio.h>

int main(int argc, char **argv) {
    tu_int a = (tu_int)0x1ec273014 << 64 | 0xff7377ffffffffffuLL;
    tu_int b = (tu_int)0x8ac7230489e80000uLL;
    tu_int r;
    tu_int q = __udivmodti4(a, b, &r);

    utwords qt;
    qt.all = q;
    utwords rt;
    rt.all = r;
    fprintf(stderr, "q=0x%.16llX%.16llX\nr=0x%.16llX%.16llX\n",
            qt.s.high, qt.s.low, rt.s.high, rt.s.low);

    return 0;
}

This corresponds to the inputs
a=152313999999999991610955792383
b=10000000000000000000

The correct result of division is
r=15231400000
q=9999991610955792383

However compiler-rt gives:
r=15231399999
q=9999991610955792383


Is this a bug?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180425/f7788ed8/attachment.html>

> On Apr 25, 2018, at 12:33 AM, Andrew Kelley via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Here is my test case:
> 
> #include <stdio.h>
> 
> int main(int argc, char **argv) {
>     tu_int a = (tu_int)0x1ec273014 << 64 | 0xff7377ffffffffffuLL;
>     tu_int b = (tu_int)0x8ac7230489e80000uLL;
>     tu_int r;
>     tu_int q = __udivmodti4(a, b, &r);
> 
>     utwords qt;
>     qt.all = q;
>     utwords rt;
>     rt.all = r;
>     fprintf(stderr, "q=0x%.16llX%.16llX\nr=0x%.16llX%.16llX\n",
>             qt.s.high, qt.s.low, rt.s.high, rt.s.low);
> 
>     return 0;
> }
> 
> This corresponds to the inputs 
> a=152313999999999991610955792383
> b=10000000000000000000
> 
> The correct result of division is
> r=15231400000
> q=9999991610955792383
> 
> However compiler-rt gives:
> r=15231399999
> q=9999991610955792383
Are your results mislabeled? Integer division rounds towards zero, so the
correct division result is 15231399999, which you have as the compiler-rt
result.

– Steve

This is a rather embarrassing mistake that I made - I simply misunderstood
Python's output:

$ python3
>>> 152313999999999991610955792383 / 10000000000000000000
15231400000.0
>>> 152313999999999991610955792383 // 10000000000000000000
15231399999

Apologies for the noise.

On Wed, Apr 25, 2018 at 10:34 AM, Stephen Canon <scanon at apple.com>
wrote:
>
>
> > On Apr 25, 2018, at 12:33 AM, Andrew Kelley via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Here is my test case:
> >
> > #include <stdio.h>
> >
> > int main(int argc, char **argv) {
> >     tu_int a = (tu_int)0x1ec273014 << 64 |
0xff7377ffffffffffuLL;
> >     tu_int b = (tu_int)0x8ac7230489e80000uLL;
> >     tu_int r;
> >     tu_int q = __udivmodti4(a, b, &r);
> >
> >     utwords qt;
> >     qt.all = q;
> >     utwords rt;
> >     rt.all = r;
> >     fprintf(stderr,
"q=0x%.16llX%.16llX\nr=0x%.16llX%.16llX\n",
> >             qt.s.high, qt.s.low, rt.s.high, rt.s.low);
> >
> >     return 0;
> > }
> >
> > This corresponds to the inputs
> > a=152313999999999991610955792383
> > b=10000000000000000000
> >
> > The correct result of division is
> > r=15231400000
> > q=9999991610955792383
> >
> > However compiler-rt gives:
> > r=15231399999
> > q=9999991610955792383
>
> Are your results mislabeled? Integer division rounds towards zero, so the
> correct division result is 15231399999, which you have as the compiler-rt
> result.
>
> – Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180425/bb32f0f4/attachment.html>