[Bug build/29501] Check failed on stdlib/tst-strfrom while building for RISCV64 on a unmatched hardware

["fantasquex at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #7 from Letu Ren <fantasquex at gmail dot com> ---
The root cause is that in function STRFROM of stdlib/strfrom-skeleton.c

```c
/* Single-precision values need to be stored in a double type, because
   __printf_fp_l and __printf_fphex do not accept the float type.  */
union {
  double flt;
  FLOAT value;
} fpnum;
const void *fpptr;
fpptr = &fpnum;

/* Single-precision values need to be converted into double-precision,
   because __printf_fp and __printf_fphex only accept double and long double
   as the floating-point argument.  */
if (__builtin_types_compatible_p (FLOAT, float))
  fpnum.flt = f;
else
  fpnum.value = f;
```


argument f with type float is converted to double in the beginning. On riscv64,
-NAN with type float doesn't keep signbit when it is converted to double. That
is why this testcase only fails with strfromf.

I have confirmed that if the signbit is kept, the testcase will pass.

I'm really curious why the implementation converts the argument to double in
the beginning and look through ISO/IEC TS 18661-1:2014.

> The strfromd, strfromf, and strfroml functions are equivalent to snprintf(s, n, format, fp) (7.21.6.5), except the format string contains only the character	 %, an optional precision that does not contain an asterisk *, and one of the conversion specifiers a, A, e, E, f, F,	g, or G, which applies to the type (double, float,	or long double)	indicated by the function suffix (rather than  by a length modifier). Use of these functions with any other 20 format string results	in undefined behavior.

Since `snprintf` doesn't consume an argument with type double, there must be a
conversion from float to double. According to spec of IEEE 754 and RISCV-ISA
manual, all these behaviors are reasonable. The signbit of NAN doesn't matter.

I understand what you mean a hook. Get the signbit of the argument, copy the
value and also copy the signbit explicitly. As I mentioned before, all current
behaviors are reasonable according to the spec. I really doubt whether we
should add such a hook to resolve a problem which shouldn't be a problem.

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