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 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.
I wonder what you can do with LOGICALs that have values transfered from
INTEGER (other than 0/1).  Does the standard define whether something
is executed or not in:
logical, parameter :: l = transfer (234, .false.)
if (l) print *, ".true."
?  I.e. is it supposed to be .false. or .true., or undefined behavior?

I guess I could in fold_view_convert_expr temporarily

  /* XXX: Fortran workaround - the FE sometimes wants BOOLEAN_TYPE semantics
     and sometimes not.  */
  if (TREE_CODE (type) == BOOLEAN_TYPE && TREE_CODE (expr) == STRING_CST)
    return NULL_TREE;

and the FE would need to make sure the STRING_CST has enough aligned type
(on the STRING_CST TREE_TYPE (string_cst) = copy_node (TREE_TYPE (string_cst));
and TYPE_ALIGN (TREE_TYPE (string_cst)) = TYPE_ALIGN (gfc_get_logical_type
(expr->ts.kind)); TYPE_USER_ALIGN (TREE_TYPE (string_cst)) = 1;),
but guess Richi isn't going to look favourably at it.  Unfortunately
the result of TRANSFER is supposed to be a constant :(, so we can't play
games with asm, volatile or some other optimization barrier.

	Jakub