Run-time noise from fp-bit:df_to_sf (truncdfsf2).

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

I don't think this has been reported before, and I'm not sure any code
should change.  I mean this as a heads-up only.  The run-time of the
fp-bit.c truncdfsf2 implementation is noisy; it depends on stack-contents.
That function is short enough to quote:

SFtype
df_to_sf (DFtype arg_a)
{
  fp_number_type in;
  USItype sffrac;
  FLO_union_type au;

  au.value = arg_a;
  unpack_d (&au, &in);

  sffrac = in.fraction.ll >> F_D_BITOFF;

  /* We set the lowest guard bit in SFFRAC if we discarded any non
     zero bits.  */
  if ((in.fraction.ll & (((USItype) 1 << F_D_BITOFF) - 1)) != 0)
    sffrac |= 1;

  return __make_fp (in.class, in.sign, in.normal_exp, sffrac);
}

If arg_a is zero, the function unpack_d will return with in.sign set,
in.class = CLASS_ZERO, and the rest unaltered (garbage; whatever was on
stack).  The if-statement that follows the call then depends on the
garbage contents of in.fraction.ll.  Note, the truncdfsf2 *result* does
not depend on this erratic behavior.

If your target uses fp-bit.c and you're into testing run-time behaviour
for all minimal changes (who doesn't?) and such a change makes a
difference that propagates to stack contents (most changes do), you'll
likely see noise in your run-time numbers for almost any test that
includes floating-point calculations.

To wit, this can turn that small change you just did, that could only have
a positive effect on run-time if any at all, to show net negative numbers.
The effect should be small for most programs (ghostscript-5.50 in my
case), but as an anomaly it's still a cause for investigation.

I can't see any obvious code correction that will not likely have a
negative run-time effect, but maybe this message will save someone some
head-scratching.  Valgrind-like simulators will warn for "conditional jump
or move depends on uninitialised value" provided that simulator marks
memory that falls below the stack pointer as undefined, like valgrind does.

I'm interested in other similar sources of noise in gcc or nearby that
people have found.  (Except for cases of using pointers as input to a hash
function.  Those are just bugs and should be fixed.)

brgds, H-P