c/2498

[Jim Wilson]

The following reply was made to PR c/2498; it has been noted by GNATS.

From: Jim Wilson <wilson@cygnus.com>
To: mark.dewing@intel.com, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c/2498
Date: Fri, 13 Apr 2001 13:03:39 -0700

 See http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00736.html for the
 patch that fixes this.
 
 I had to spend some time studying the documentation before I could figure out what was going on.
 
 The problem here is that the in register representation of denorms uses a different exponent than
 
 the in memory representation.  Specifically, the exponent is one instead of zero.  This makes
 
 sense from an arithmetic logic perspective, as it makes arithmetic easier.  This requires conversion
 
 of the exponent when changing between register and memory formats.  This conversion is done by
 
 anding the exponent with the leading bit of the significand, which forces the exponent to zero if
 
 this is a denorm.  Thus a single denorm in-register gets translated to a double denorm in-memory
 
 which has the wrong value.  If the exponent conversion was done by subtracting one from the exponent
 
 then we would get a unnormalized double with the right value, and things might still work, but
 
 an and is faster than a adder, so I can see why this was done.
 
 The fact that stf and getf require normalization is not as well documented as it could be.
 
 Neither the stf nor getf documentation in the SDM Vol 3 mention this.  However, both of them use
 
 the fp_fr_to_mem function in the Operations description, and looking that up in the appendix I
 
 see that it is documented that this function requires its inputs to be normalized.  I also checked
 
 SDM Vol 1 Section 5 which discuss the FP model.  Section 5.3.1 which documents stf does mention
 
 that the value must be normalized first.  However, the following section which documents getf
 
 does not.
 
 Anyways, I understand now that normalization is required for getf and stf, so now we always emit
 
 an fnorm for a FP cast.  We can still eliminate the fnorm if we know that the next instruction
 
 is not getf or stf, but I'm leaving that for a later optimization.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2498&database=gcc