public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug math/27855] New: powf raises FPE_FLTUND on non-subnormal base value
@ 2021-05-12  5:12 kip at thevertigo dot com
  2021-05-12 16:36 ` [Bug math/27855] " joseph at codesourcery dot com
  0 siblings, 1 reply; 2+ messages in thread
From: kip at thevertigo dot com @ 2021-05-12  5:12 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=27855

            Bug ID: 27855
           Summary: powf raises FPE_FLTUND on non-subnormal base value
           Product: glibc
           Version: 2.32
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: kip at thevertigo dot com
  Target Milestone: ---

This may be a bug, or it might be I am doing something wrong.

There does not appear to be any reliable way of determining whether the
arguments to powf will raise a FPE_FLTUND when subnormals are trapped. One
might expect that if the base is a subnormal, that should be a good reason to
anticipate the function will break. However even FP_NORMAL values can break it.

In the following minimal, note that if A, B, and Base are changed to constexpr,
no FPE is raised. No FPE is raised if there is any optimization level beyond
-O0. If the exponent remains positive but less than 4, no FPE.

#include <cassert>
#include <cfenv>
#include <cmath>
#include <iostream>

using namespace std;

int main()
{
  ::feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW | FE_UNDERFLOW);

    float A = 5.22049903e-10f;
    float B = 3.91528365e-10f;

    float Base = A - B;

    float Result = powf(Base, 4);

    cout << fixed << Result << endl;

    return 0;
}

$ g++-10 test.cpp -O0 -o test && gdb ./test
Reading symbols from ./test...
(No debugging symbols found in ./test)
(gdb) r
Starting program: /home/kip/Desktop/test 

Program received signal SIGFPE, Arithmetic exception.
0x00007ffff7ce791e in __powf_fma (x=<optimized out>, y=<optimized out>) at
../sysdeps/ieee754/flt-32/e_powf.c:120
120     ../sysdeps/ieee754/flt-32/e_powf.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7ce791e in __powf_fma (x=<optimized out>, y=<optimized out>) at
../sysdeps/ieee754/flt-32/e_powf.c:120
#1  0x000055555555525c in main ()
(gdb) 

This also does not appear to be a problem with gcc, or at least not
exclusively. clang does the same thing:

https://godbolt.org/z/5qTzfbfKe

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug math/27855] powf raises FPE_FLTUND on non-subnormal base value
  2021-05-12  5:12 [Bug math/27855] New: powf raises FPE_FLTUND on non-subnormal base value kip at thevertigo dot com
@ 2021-05-12 16:36 ` joseph at codesourcery dot com
  0 siblings, 0 replies; 2+ messages in thread
From: joseph at codesourcery dot com @ 2021-05-12 16:36 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=27855

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Underflow should be raised if the result is tiny and inexact (where a 
result very close to the threshold for being tiny may be treated as if 
there were a tiny result with a small rounding error, and raise 
underflow).  If the mathematical result is tiny and exact, it's 
unspecified for functions such as powf that aren't bound to IEEE 
operations whether they might raise underflow exceptions (strictly, in the 
case where trapping is enabled, they ought to raise underflow without 
inexact, but glibc doesn't attempt to ensure the exact underflow cases 
necessarily do raise the exception).

It's best to report libm issues with hex float values of the arguments 
rather than giving them as the result of arithmetic on values given in 
decimal as here.  A hex float argument would make it more obvious whether 
the result should be exact or not, for example.

Whether the base value is subnormal is irrelevant, it's all about the 
result of the function (the mathematically exact result and the result 
actually returned).  What is the value powf returns for you (as a hex 
float), with trapping disabled, and what exceptions are raised by the call 
as shown with fetestexcept (we should disentangle the rarely-used trapping 
functionality from the standard support for raising flags, so if the issue 
can be shown in terms only of flags raised, we should look at it in that 
form)?  What is the correctly rounded return value?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-05-12 16:36 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-12  5:12 [Bug math/27855] New: powf raises FPE_FLTUND on non-subnormal base value kip at thevertigo dot com
2021-05-12 16:36 ` [Bug math/27855] " joseph at codesourcery dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).