TestLinuxCore: two aarch64 reg test cases fail on FreeBSD/aarch64

[Quuxplusone]

Bugzilla Link	PR49415
Status	NEW
Importance	P enhancement
Reported by	Michał Górny (mgorny@gentoo.org)
Reported on	2021-03-03 10:54:25 -0800
Last modified on	2021-03-24 09:00:37 -0700
Version	unspecified
Hardware	PC Linux
CC	arichardson.kde@gmail.com, emaste@freebsd.org, jdevlieghere@apple.com, labath@google.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

FAIL: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) ::
test_aarch64_regs (TestLinuxCore.LinuxCoreTestCase)
FAIL: LLDB (/home/mgorny/llvm-project/build.arm64/bin/clang-aarch64) ::
test_aarch64_sve_regs_fpsimd (TestLinuxCore.LinuxCoreTestCase)

The results look a bit suspicious -- like a rounding/printing problem.  I
wonder if it could be affected by some subtle stdlib difference.

======================================================================
FAIL: test_aarch64_regs (TestLinuxCore.LinuxCoreTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 149, in wrapper
    return func(*args, **kwargs)
  File "/home/mgorny/llvm-project/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py", line 348, in test_aarch64_regs
    substrs=["{} = {}".format(regname, value)])
  File "/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2566, in expect
    self.fail(log_msg)
AssertionError: Ran command:
"register read d4"

Got output:
      d4 = 0

Expecting sub string: "d4 = 5.35161536149201e-315" (was not found)
Config=aarch64-/home/mgorny/llvm-project/build.arm64/bin/clang
======================================================================
FAIL: test_aarch64_sve_regs_fpsimd (TestLinuxCore.LinuxCoreTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 149, in wrapper
    return func(*args, **kwargs)
  File "/home/mgorny/llvm-project/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py", line 435, in test_aarch64_sve_regs_fpsimd
    substrs=["{} = {}".format(regname, value)])
  File "/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2566, in expect
    self.fail(log_msg)
AssertionError: Ran command:
"register read d4"

Got output:
      d4 = 0

Expecting sub string: "d4 = 5.35161536149201e-315" (was not found)
Config=aarch64-/home/mgorny/llvm-project/build.arm64/bin/clang
----------------------------------------------------------------------
Ran 18 tests in 37.985s

RESULT: FAILED (16 passes, 2 failures, 0 errors, 0 skipped, 0 expected
failures, 0 unexpected successes)

[Quuxplusone]

Given a simple example:

#include <stdio.h>

int main() {
    printf("%e\n", 5.35161536149201e-315);
    return 0;
}

on FreeBSD/amd64 and Linux/aarch64 (openSUSE) it prints:

$ ./a.out 5.351615e-315

but on FreeBSD/aarch64:

$ ./a.out 0.000000e+00

[Quuxplusone]

Interesting. I guess we should convert whoever is printing this from printf to llvm::APFloat...

[Quuxplusone]

Could this perhaps be due to the issue fixed in https://cgit.freebsd.org/src/commit/?id=0e4ff0acbe80c547988bede738af2e227c7eb47c

[Quuxplusone]

I'm going to try.

[Quuxplusone]

Nope, still the same result as of freebsd 0cff00ae682a032dec29494f88c76d78a08edfa1.

[Quuxplusone]

That commit should definitely fix the issue. If I run the following .c file on a RPI4, I get the expected output once the FTZ flag is cleared.

[root@rpi4-002 ~]# cat ftz_test.c
#include <stdio.h>
#include <stdint.h>
#include <fenv.h>
#include <machine/vfp.h>
#define VFPCR_FZ                (0x01000000)    /* flush to zero enabled */

int main() {
    volatile double d = 5.35161536149201e-315;
    unsigned long fpcr;
    __mrs_fpcr(fpcr);
    printf("fpcr=%lx\n", fpcr);
    printf("FTZ=%lx\n", fpcr & VFPCR_FZ);
    printf("d=%g\n", d);
    fpcr &= ~(long)VFPCR_FZ;
    __msr_fpcr(fpcr);
    __mrs_fpcr(fpcr);
    printf("fpcr=%lx\n", fpcr);
    printf("FTZ=%lx\n", fpcr & VFPCR_FZ);
    printf("d=%g\n", d);
}
[root@rpi4-002 ~]# cc -o ftz ftz_test.c
[root@rpi4-002 ~]# ./ftz
fpcr=3000000
FTZ=1000000
d=0
fpcr=2000000
FTZ=0
d=5.35162e-315

[Quuxplusone]

Note: If you are using a recent FreeBSD HEAD/stable-13 kernel the first printf should output "fpcr=2000000" rather than "fpcr=3000000". If not, my guess would be something went wrong during the update process.

[Quuxplusone]

I'm getting the same output from your program. Did you try mine (#c1)?

[Quuxplusone]

(the same as you do, i.e. it works)

[Quuxplusone]

I am running an old kernel that doesn't have the fix so I am also seeing zero output. But in QEMU with a new kernel that has the fix I see non-zero output for your test program.

Since you are seeing my output that means you are running a kernel that still sets the flush-to-zero flag.

[Quuxplusone]

Ah, sorry, I misunderstood you. I'll update the kernel then.

[Quuxplusone]

Indeed this fixes it. Should I remove xfail now and close the bug or wait some more?

[Quuxplusone]

This change is not yet in FreeBSD 13.0, and I am not yet sure if it will be possible to include it. I should know in the next day or two. If it does get included I think we can just drop the xfail.

[Quuxplusone]

The change is now merged and will be in FreeBSD 13.0. I think we can drop the xfail (but probably leave a comment that this was fixed in FreeBSD 13.0, in case anyone tries on FreeBSD/arm64 12.2).