Re: [PATCH] Fold VIEW_CONVERT_EXPR <type, STRING_CST> generated by Fortran FE a lot (PR target/35366)

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Nov 11, 2008 at 06:01:52PM +0100, Tobias Schlüter wrote:
> Jakub Jelinek wrote:
>> On Tue, Nov 11, 2008 at 05:21:36PM +0100, Tobias Schlüter wrote:
>>> Hm, I haven't found Richard Maine's post that is mentioned in the old 
>>>  thread, but Fortran has the notion of storage unit.  LOGICAL*4,   
>>> INTEGER*4 and REAL*4 all occupy 4 storage units.  If a circular   
>>> transfer(transfer (...) ...) between types with the same number of   
>>> storage units is required to return the original value (as Richard 
>>> Maine  apparently argued), then we'll probably have no choice but to 
>>> stop using  BOOLEAN_TYPE for LOGICALs.
>>
>> That's pretty sad.  Stopping using BOOLEAN_TYPE is going to break
>> basically everything, so certainly can't be done for 4.4.  I expect
>> that you'd need to add a lot of conversions everywhere, from the
>> logical*N INTEGER_TYPE to correspondingly sized BOOLEAN_TYPE and back
>> all the time.
>
> Maybe setting TYPE_PRECISION to bit_size in gfc_build_logical_type()  
> would do the trick without any further changes?  This depends on how the  
> middle-end deals with BOOLEAN_TYPES with TYPE_PRECISION > 1.

It wouldn't help:

/* Boolean type (true or false are the only values).  Looks like an
   INTEGRAL_TYPE.  */
DEFTREECODE (BOOLEAN_TYPE, "boolean_type", tcc_type, 0)

On the other side, if you have to convert from INTEGER_TYPE to BOOLEAN_TYPE
all the time, the generated code will be very abysmal.

How is LOGICAL supposed to behave if it is storage associated with an
integer?  Defined only if the integer stored has been 0 or 1, or 0 .false.
and non-zero .true., or something else?

Also, even with my patch
integer, parameter :: i = transfer (transfer (42, .true.), 0)
will work as the standard requires (in this case the transfers
are resolved in the FE, and only one VIEW_CONVERT_EXPR is created
(and folded to 42).  But that's not what is failing in
transfer_simplify_4.f90.  What fails is:
  a = transfer(ip1, .true.)
  i = transfer(a, 0)
  if (i .ne. ip1) call abort ()
(as ip1 is parameter, then this is the same as
  a = transfer(42, .true.)
  i = transfer(a, 0)
  if (i .ne. ip1) call abort ()
).  If I modify the testcase slightly:

  implicit none
  integer :: ip1
  logical :: a
  integer :: i
  ip1 = 42
  a = transfer(ip1, .true.)
  i = transfer(a, 0)
  if (i .ne. ip1) call abort ()
end

then it fails even with unpatched gfortran (even with 4.3) at -O1 and higher.
But does the standard really say anything about this?  Isn't assignment
to a LOGICAL value supposed to set to to .false. or .true.?

	Jakub