[patch, fortran] PR35223 IBITS gives compiler error

Jerry DeLisle jvdelisle@verizon.net
Sun Feb 24 02:13:00 GMT 2008


FX Coudert wrote:
>> 2008-02-23  Jerry DeLisle  <jvdelisle@gcc.gnu.org>
>>
>>     PR fortran/35223
>>     * simplify.c (gfc_simplify_ibclr), (gfc_simplify_ibits),
>>     (gfc_simplify_ibset): Remove call to range_check.
>>     (simplify_cmplx), (gfc_simplify_dble), (gfc_simplify_float),
>>     (gfc_simplify_real): Add call gfc_clear_ts to initialize the 
>> temporary
>>     gfc_typspec variables.
> 
> It is not clear to me from the PR discussion whether you do this for 
> user-friendliness or because the checks are actually not mandated by the 
> standard. I think I understand it is the last one but, for my 
> enlightenment, I'd like to make sure I am not misunderstanding.
> 
> If the checks are not mandated by the standard, they can go. If it's for 
> user-friendliness... then it seems a bit incoherent with other cases.
> 
> FX
> 
This range check is not mandated by the standard.  The standard provides two 
models, one for bit manipulation and one for numerical.  In both models the 
entity is described by a series of bits (for example, 32 bits wide)

The bit-manipulation intrinsics are permitted full access to all 32 bits under 
their model.  When an entity has been bit manipulated and is then assigned to 
another entity that falls under the numerical model, the numerical model takes 
affect after the assignment. The bits are simply mapped from one model to the other.

Another way to look at this is that the bit manipulation model has no concept of 
range.

Now interestingly we still have a problem without the range check:

program test_ibits
   real :: r
   integer :: i
   i = ibits (-1, 0, bit_size (0))
   r = ibits (-1, 0, bit_size (0))
   write (*, *) r, i, ibits (-1, 0, bit_size (0))
end program test_ibits

gfortran:

$ gfc ibits.f90
$ ./a.out
   4.29496730E+09          -1          -1

ifort:

$ ifort ibits.f90
$ ./a.out
   -1.000000              -1          -1

sun f95
$ sf95 ibits.f90
$ ./a.out
  -1.0 -1 -1

So I withdraw the first patch and attach a new one.  The new patch fixes this 
new problem by first converting to unsigned, then doing the bit manipulation, 
and converting back to signed.  Again, the two models described in the standard.

Incidentally, this conversion to unsigned and back to signed is done already in 
ibset and ibclr

I am still regression testing this new patch.  It yields:

$ ./a.out
  -1.00000000              -1          -1

With or without range_check on the final result.

I will hold on any commit until we have consensus.


Jerry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr35223-a.diff
Type: text/x-patch
Size: 2291 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080224/f220b75f/attachment.bin>


More information about the Gcc-patches mailing list