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

[llvmbot]

Bugzilla Link	49415
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@arichardson,@emaste,@JDevlieghere,@labath

Extended Description

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)

[llvmbot]

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

[labath]

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

[emaste]

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

[llvmbot]

I'm going to try.

[llvmbot]

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

[arichardson]

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

[arichardson]

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.

[llvmbot]

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

[llvmbot]

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

[arichardson]

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.

[llvmbot]

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

[llvmbot]

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

[emaste]

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.

[emaste]

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).