Re: port-i386/58434: single-float functions sometimes return surprisingly much precision

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

Annotated listing of the relevant disassembly fragment for
printf("log1pf(1)=%a=%a\n", log1pf(1), log1pf(1)), where y denotes the
extended precision result of log(1 + x):

	...
	call	log1pf		# evaluate second argument first
				# fp stack: y
	fstps	0x28(%esp)	# pop fp stack and write (float)y to
				# memory in single-precision
				# fp stack: (empty)
	...
	call	log1pf		# evaluate first argument second
				# fp stack: y
	flds	0x28(%esp)	# push (float)y from memory on fp stack
				# fp stack: (float)y y
	fstpl	0xc(%esp)	# pop fp stack and write (double)(float)y
				# to second printf format argument
				# fp stack: y
	fstpl	0x4(%esp)	# pop fp stack and write (double)y
				# to first printf format argument
				# fp stack: (empty)
	movl	...,(%esp)	# set printf format string
	call	printf

But different compilers might do it differently!  The gcc12 shipped in
Debian 12 saves the intermediate result with fstpl in double-precision
rather than with fstps in single-precision.  So the output there is:

log1pf(1)=0x1.62e42fefa39efp-1=0x1.62e42fefa39efp-1
log1p(1)=0x1.62e42fefa39efp-1=0x1.62e42fefa39efp-1

And of course nothing constrains the compiler's order of evaluation or
order of explicitly rounding intermediate results, so one could also
see

log1pf(1)=0x1.62e43p-1=0x1.62e42fefa39efp-1
log1p(1)=0x1.62e42fefa39efp-1=0x1.62e42fefa39efp-1

but I haven't (yet) seen this in practice.