Stephan Rudlof <sr at evolgo.de> wrote
	please compile
	[some technically flawed C code involving a call to
	 sin(1.0e20)]
	[using gcc, with and without optimisation]

Across a range of modern 32- (and 64-) bit machines claiming to support
IEEE floating point arithmetic, I consistently get
sin(1.000000e+20) = -6.452513e-01
and it doesn't matter whether I use gcc or something else
and it doesn't matter whether I optimise or not.

None of these machines has an 80-bit floating-point format,
and none of them has ever had special instructions for transcendental
functions, unlike *86's with their *87 history.

I note that IEEE doubles have about 56 bits of precision, while
1.0e20 is approximately 2**66.44, so that *all* the bits of the
result are going to be noise anyway.  Put another way, a relative
error of half a unit in the least significant bit of 1.0e20
amounts to a couple of hundred complete cycles of sin(), so
there's no way the result is going to mean much, and pretty much
any answer in the range [-1,+1] would be ok.  That doesn't excuse
other kinds of errors, of course.

Instead of just
	gcc -O testDoubles.c -lm
	gcc    testDoubles.c -lm
how about
	gcc -S -O testDoubles.c
and	gcc -S    testDoubles.c
from someone with a Linux box so that we know what the code is?