Bug 224326

Created attachment 188840 [details]
program to display correct values (except for rounding errors)

This is a simple program I wrote to get the expected values (compared also with glibc output, they differ in the two less significant digits at position 17)

Comment 2 Piotr Pawel Stefaniak 2021-10-05 20:04:47 UTC

I'm getting the expected output, but this is on amd64 and stable/13.

Comment 3 Piotr Pawel Stefaniak 2021-10-09 11:15:08 UTC

Actually, below is what I'm getting on stable/13.

amd64:
$ ./test | tail
0x0000000000000200 2.5296161067071825d-321
0x0000000000000100 1.2648080533535913d-321
0x0000000000000080 6.3240402667679563d-322
0x0000000000000040 3.1620201333839781d-322
0x0000000000000020 1.5810100666919891d-322
0x0000000000000010 7.9050503334599451d-323
0x0000000000000008 3.9525251667299726d-323
0x0000000000000004 1.9762625833649863d-323
0x0000000000000002 9.8813129168249318d-324
0x0000000000000001 4.9406564584124659d-324

arm64:
% ./test | tail
0x0000000000000200 2.5296161067071825d-321
0x0000000000000100 1.2648080533535913d-321
0x0000000000000080 6.3240402667679563d-322
0x0000000000000040 3.1620201333839781d-322
0x0000000000000020 1.5810100666919891d-322
0x0000000000000010 7.9050503334599451d-323
0x0000000000000008 3.9525251667299726d-323
0x0000000000000004 1.9762625833649863d-323
0x0000000000000002 9.8813129168249318d-324
0x0000000000000001 4.9406564584124659d-324

So better than 
0x0000000000000200 1.1125369292537272e-308
0x0000000000000100 1.1125369292536639e-308
0x0000000000000080 1.1125369292536323e-308
0x0000000000000040 1.1125369292536165e-308
0x0000000000000020 1.1125369292536086e-308
0x0000000000000010 1.1125369292536046e-308
0x0000000000000008 1.1125369292536027e-308
0x0000000000000004 1.1125369292536017e-308
0x0000000000000002 1.1125369292536012e-308
0x0000000000000001 1.1125369292536009e-308
but not exactly
0x0000000000000200 2.5296161067071823e-321
0x0000000000000100 1.2648080533535912e-321
0x0000000000000080 6.3240402667679558e-322
0x0000000000000040 3.1620201333839779e-322
0x0000000000000020 1.5810100666919889e-322
0x0000000000000010 7.9050503334599447e-323
0x0000000000000008 3.9525251667299724e-323
0x0000000000000004 1.9762625833649862e-323
0x0000000000000002 9.8813129168249309e-324
0x0000000000000001 4.9406564584124654e-324

Hi Piotr,

Yeah, on intel it works.... I was working in a raspberry pi, model 2+, which is where I addressed the bug (more than four years ago!!!!)  The expected behaviour was produced by running the program in intel architecture.

I think the bug is related with the raspberry processor not supporting subnormals and the software accepting them as they are in intel, But I have no time to dig on this problem.  My apologies.

Comment 5 Piotr Pawel Stefaniak 2021-10-12 16:17:03 UTC

(In reply to Luis Colorado from comment #4)

Please note that "arm64" in comment #3 is non-intel (although not RPi as in your case but the first pinebook).

arm64 is not the architecture I'm talking about, as the rpi 2+ is 32 bit arch and not arm64.  Anyway I suspect the problem will be also there, as both architectures will probably share the floating point unit.

But you tell me that you are getting correct results in AMD64 (which is the intel 64 bit architecture, and not ARM at all)  Sorry, but I don't get the point here.  It is four years this bug is rolling over there.  My impression is that arm architectures don't support 64bit floating point subnormals at all, and that's the reason the software is failing, as it doesn't cut the thing and makes them as 0 (which obviously the hardware is not doing)

IMHO, the floating point library should check if the processor supports subnormals or not, which is something required by the ieee standard, and round the values to 0.0, instead.  That is easy to check, as the exponent field is all zeros for subnormals.

(In reply to Luis Colorado from comment #4)

RPi2 v1.0 and v1.1 were Cortex-A7 (armv7) based.
RPi2 v1.2 was Cortext-A53 (aarch64) based.

(I sometimes have access to a v1.1 and/or v v1.2, but
not currently.)

RPi2 v1.2's can use either armv7 FreeBSD or aarch64 
FreeBSD.

So things can be confusing/ambiguus when RPi2 is used as
a point of reference. SO it is better to specify which
FreeBSD is in use, such as via:

# uname -apKU
FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT #10 main-n249978-032448cd2c52-dirty: Sat Oct  9 02:11:35 PDT 2021     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.armv7/sys/GENERIC-NODBG-CA7  arm armv7 1400036 1400036

(Not an RPi* example.)

(In reply to Luis Colorado from comment #0)

On/for armv7, for compiling/linking the test program via
any of:

system clang (so: 12)
clang13 (from devel/llvm13)
gcc11 (from lang/gcc11)

and then running the test, all produce the e-308 "from here
on, all are incorrect" type of results.

Side note:

For reference,

# gcc11 -O2 -pedantic -Wall subnormal_test.c
subnormal_test.c: In function 'main':
subnormal_test.c:10:49: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   10 |                 printf("0x%016llx %-0.17lg\n", *(unsigned long long *)&val, val);
      |                                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
subnormal_test.c:10:24: warning: '0' flag ignored with '-' flag in gnu_printf format [-Wformat=]
   10 |                 printf("0x%016llx %-0.17lg\n", *(unsigned long long *)&val, val);
      |                        ^~~~~~~~~~~~~~~~~~~~~~

and:

# clang13 -O2 -pedantic -Wall subnormal_test.c
subnormal_test.c:10:23: warning: flag '0' is ignored when flag '-' is present [-Wformat]
                printf("0x%016llx %-0.17lg\n", *(unsigned long long *)&val, val);
                                  ~~^~~~~~

(In reply to Mark Millard from comment #8)

For gcc11 I forgot : -Wl,-rpath=/usr/local/lib/gcc11
so that:

# ldd a.out
a.out:
        libgcc_s.so.1 => /usr/local/lib/gcc11/libgcc_s.so.1 (0x2008d000)
        libc.so.7 => /lib/libc.so.7 (0x200bc000)

(Not that it makes any difference in the bad -e308's that result.)