A possible bug in parsing floating point numbers.

[Kazu Hirata]

Hi Zack,

> 	* real.h: Kill single-letter macros in definition of
> 	REAL_VALUE_TYPE.  New macro REAL_VALUE_TYPE_SIZE, is either 96
> 	or 160.  Use it to define REAL_WIDTH; use REAL_WIDTH to size
> 	REAL_VALUE_TYPE.  The upshot is, REAL_VALUE_TYPE is always
> 	either 96 or 160 bits wide, such that real.c's "UEMUSHORT e[NE]"
> 	format always fits it exactly.  Provide CONST_DOUBLE_FORMAT.
> 	Issue #error for unsupported REAL_WIDTH rather than relying on
> 	later syntax errors.
> 	* real.c: Nuke EMU_NON_COMPILE (which would have gone by
> 	silently until the link failed) in favor of #error.
> 	Disentangle calculation of NE; document that it's always
> 	either 96 or 160 bits.  Cause compile to fail if
> 	REAL_VALUE_TYPE doesn't fit UEMUSHORT e[NE] exactly.  Always
> 	define GET_REAL and PUT_REAL as bare memcpy-s.
> 
> 	* gengenrtl.c, rtl.c: Delete logic to calculate REAL_WIDTH and
> 	CONST_DOUBLE_FORMAT; now provided by real.h.

Thanks for the patch.  I just ran the testsuite with h8300-hms as a
target.  The regressions caused late March now seem to be all gone.
Although I haven't checked actual encoding of floating point numbers
in assembly code, I suppose they are all right.

Kazu Hirata