• Re: arm64, valgrind floating point instruction produces different resul

    From =?UTF-8?Q?Bernhard_=C3=9Cbelacker?=@21:1/5 to All on Thu Jun 27 03:10:01 2024
    This is a multi-part message in MIME format.
    Am 26.06.24 um 21:31 schrieb Jeffrey Walton:

    Is there some knowledge about such an issue, or how to avoid this?

    [1071656] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071656

    I'm not sure if it matters, but Valgrind added support for the fcvtas
    using the following register types. See <https://valgrind.org/docs/manual/dist.news.old.html> and <https://bugs.kde.org/show_bug.cgi?id=340509>.

    fcvtas w12, s1

    I think the difference between dN (your example) and sN (valgrind)
    register are bit widths. dN is 32-bit, and sN is 16-bit.

    (This may be a rabbit hole).

    Jeff


    Hello Jeff,
    thanks for this information.
    That sounds like this might be just a plain bug in valgrind?
    (And my thinking of how valgrind works was quite wrong.)

    I tried to take a look and I guess one interesting part is in [1],
    where the fcvtas gets translated into the immediate representation
    with a rounding mode `Irrm_NEAREST`, the same as fcvtns.

    In [2] is another "rounding mode conversion" and in [3] it looks
    like it gets translated back to an instruction for the real
    execution in the cpu, but unfortunately this is maybe a fcvtns,
    which therefore does not return the desired value.

    Valgrind's intermediate representation knows another rounding
    mode Irrm_NEAREST_TIE_TOWARD_0 which may fit the fcvtas better,
    but it looks like this gets no translation in [2].


    So I guess the best would be to simply report it to the
    valgrind bug tracker now?


    Kind regards,
    Bernhard





    [1] https://sourceware.org/git/?p=valgrind.git;a=blob;f=VEX/priv/guest_arm64_toIR.c;h=c3957bf58b269c1863d7246865f5ba6225bad3ca;hb=HEAD#l15940

    [2] https://sourceware.org/git/?p=valgrind.git;a=blob;f=VEX/priv/host_arm64_isel.c;h=645358586f3459d885506512277221cfa1909871;hb=HEAD#l1925

    [3] https://sourceware.org/git/?p=valgrind.git;a=blob;f=VEX/priv/host_arm64_defs.c;h=0b59c87cd3bddf3cb8374414cd8e065c660926a3;hb=HEAD#l4459

    [4]
    benutzer@chroot-13-trixie-unstable:~$ gcc -g -O2 fp-valgrind-test.c -o fp-valgrind-test
    benutzer@chroot-13-trixie-unstable:~$ ./fp-valgrind-test
    i=0 a=-322.500001 a=0xc0742800010c6f7a b=-323
    i=1 a=-322.500000 a=0xc074280000000000 b=-323 <<<
    i=2 a=-322.499999 a=0xc07427fffef39086 b=-322
    i=3 a=322.499999 a=0x407427fffef39086 b=322
    i=4 a=322.500000 a=0x4074280000000000 b=323 <<<
    i=5 a=322.500001 a=0x40742800010c6f7a b=323 benutzer@chroot-13-trixie-unstable:~$ valgrind ./fp-valgrind-test
    ==35570== Memcheck, a memory error detector
    ==35570== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==35570== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==35570== Command: ./fp-valgrind-test
    ==35570==
    i=0 a=-322.500001 a=0xc0742800010c6f7a b=-323
    i=1 a=-322.500000 a=0xc074280000000000 b=-322 <<<
    i=2 a=-322.499999 a=0xc07427fffef39086 b=-322
    i=3 a=322.499999 a=0x407427fffef39086 b=322
    i=4 a=322.500000 a=0x4074280000000000 b=322 <<<
    i=5 a=322.500001 a=0x40742800010c6f7a b=323
    ==35570==

    LyoKY2F0IGZwLXZhbGdyaW5kLXRlc3QuYwpnY2MgLWcgLU8yIGZwLXZhbGdyaW5kLXRlc3Qu YyAtbyBmcC12YWxncmluZC10ZXN0Ci4vZnAtdmFsZ3JpbmQtdGVzdAp2YWxncmluZCAuL2Zw LXZhbGdyaW5kLXRlc3QKZ2RiIC1xIC0tYXJncyAuL2ZwLXZhbGdyaW5kLXRlc3QKZGlzYXNz ZW1ibGUgbWFpbgpxCiovCgojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPG1hdGguaD4K CmRvdWJsZSBfX2F0dHJpYnV0ZV9fKChvcHRpbWl6ZSgiTzAiKSkpIHZhbHVlKGludCBzKQp7 CiAgc3dpdGNoIChzKSB7CiAgICBjYXNlIDA6ICByZXR1cm4gLTMyMi41MDAwMDE7IGJyZWFr OwogICAgY2FzZSAxOiAgcmV0dXJuIC0zMjIuNTsgICAgICAgYnJlYWs7CiAgICBjYXNlIDI6 ICByZXR1cm4gLTMyMi40OTk5OTk7IGJyZWFrOwogICAgY2FzZSAzOiAgcmV0dXJuICAzMjIu NDk5OTk5OyBicmVhazsKICAgIGNhc2UgNDogIHJldHVybiAgMzIyLjU7ICAgICAgIGJyZWFr OwogICAgZGVmYXVsdDogcmV0dXJuICAzMjIuNTAwMDAxOyBicmVhazsKICB9Cn0KCmludCBt YWluKCkKewogIGZvciAoaW50IGkgPSAwOyBpIDwgNjsgaSsrKSB7CiAgICBkb3VibGUgYSA9 IHZhbHVlKGkpOwogICAgaW50IGIgPSAoaW50KXJvdW5kKGEpOwogICAgcHJpbnRmKCJpPSVk IGE9JWYgYT0weCVsbHggYj0lZFxuIiwgaSwgYSwgKihsb25nIGxvbmcgdW5zaWduZWQgaW50 KikmYSwgYik7CiAgfQp9Cg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Bernhard_=C3=9Cbelacker?=@21:1/5 to All on Thu Jun 27 23:50:01 2024
    Am 27.06.24 um 02:51 schrieb Bernhard Übelacker:


    So I guess the best would be to simply report it to the
    valgrind bug tracker now?


    And I did now create an upstream bug,
    sorry for the noise and thanks for reading.


    https://bugs.kde.org/show_bug.cgi?id=489338

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)