https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #16 from joseph at codesourcery dot com <joseph at codesourcery dot
com> ---
On Thu, 3 Jan 2019, iains at gcc dot gnu.org wrote:
> Unfortunately, there doesn't appear to be anything in the GCC test suite that
> catches this (all languages reg-strap was clean, on gcc110). Does it show for
> a 32b multilib on a 64b host, or only with a 32b host?
All my testing has been for x86_64-linux-gnu host, powerpc-linux-gnu
target, --disable-multilib --with-float=soft.
The issue appears when a test built with a compiler without the problem
patch is run with glibc built with a compiler with the patch, so it looks
like something miscompiled in glibc - but it also seems sensitive to e.g.
the exact compilation options used for compiling the test with the
non-buggy compiler (as would be expected if e.g. the buggy compiler is
generating code that's using uninitialized or overwritten data in some way
and so details that should be irrelevant end up mattering). I'll look for
a specific object file in glibc that shows the issue if built with the
buggy compiler and inserted in glibc otherwise built with the non-buggy
compiler. The current cut-down version of the glibc test I have (built
with -lm -O2 -fno-builtin with GCC 8 branch just before the change) is:
float nextafterf (float, float);
int printf (const char *, ...);
static void
check_ulp (void)
{
float ulps, value;
value = nextafterf (10, 20);
/* Should print 0x1.400002p+3. */
printf ("%a\n", value);
for (int i = 1; i < 100; i++)
value = nextafterf (value, 20);
ulps = __builtin_fabsf (value - 10);
/* Should print 0x1.9p-14; buggy case hangs before this. */
printf ("%a\n", ulps);
}
int
main (void)
{
check_ulp ();
}
