This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug math/19280] [2.22 Regression] gfortran.dg/bessel_6.f90


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

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #3 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Still insufficient information.  Please provide a test in C that involves
exactly one call to whatever function is said to be buggy, with a hex float
value as input.  I can't even tell from this test whether it is jn, jnf or jnl
that is said to have a bug, let alone what the inputs to the function are.  Nor
can I tell what the expected results are.

Several of what appear to be inputs in your Fortran test are numbers such as
475.78 that are not exactly representable in binary floating point.  As such,
if Fortran semantics or the front end were to compute expected results based on
such a number interpreted in different precision to the function called at
runtime, a large error would indicate a bug in the testcase, not a bug in
glibc.  This illustrates the importance of providing a C test with hex float
inputs and expectations (and the hex float inputs being in the correct
precision for the C function in question so no implicit conversions are
involved).

Since this is for 32-bit x86, my guess is that the test is involving
numerically sensitive cases, where slight perturbations of compiler code
generation affecting where excess precision occurs internally can cause large
changes to results.  This is not of course a regression since it would just
move around slightly where the most inaccurate cases are.  It would also be a
bug in the GCC testcase that it's testing such numerically sensitive cases (in
addition to any bug if the expectations are based on computations for an input
in the wrong precision).

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]