Re: ARGH. Who wrote intrinsic_set_exponent.f90?

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Mon, Aug 28, 2006 at 10:33:29PM +0800, Feng Wang wrote:
> >  It is using nonconforming code, and
> > gfortran's handling of BOZ constants does not do what 
> > you think.
> 
> Could you explain more about "nonconforming"?

See below.

> I tested it on i686, ia64 platform and gfortran works well with it.

With my patch?

> >  Here's a excerpt of the brokeness.
> 
> >   subroutine test_real4()
> >     real x,y
> >     integer i,n
> >     equivalence(x,i)
> >     n = 128
> >     i = o'00037777777'       ! <-- This doesn't do what you think.
> >     y = set_exponent (x, n)  ! <-- This is nonconforming.
> >     if (exponent (y) .ne. n) call abort()
> >   end subroutine
> 
> In the test, we want to build an IEEE-754 denormalized floating-point
> number with its exponent -127. i shared the same memory with x.

You can share the memory.  You can assign something to i.  But,
technically you are not allowed to reference x until you assign
something to it.  Carefully, read section 14 of F95 or section
16 of F2003 about when a variable becomes defined and undefined. 

> We assign o'00037777777' to i.

If integer(kind=n) is the integer type with the largest decimal
range, then a BOZ is converted to an integer(n).  Thus, on a
system with integer(n=8), a BOZ is converted to an integer(8)
constant.  On a system with integer(n=16), a BOZ is converted to
an integer(16).  I haven't convert the above BOZ into an 
actual decimal integer value, but you should be able to do

    i = 2345613
    x = tansfer(i,x)

to get the bit pattern you want (although this isn't portable
because of endian issues).

-- 
Steve