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

[Brooks Moses <brooks at codesourcery dot com>]

Jakub Jelinek wrote, at 11/11/2008 11:12 AM:
> As I said earlier, transfer (transfer (234, .false.), 0) is already
> identity, as that never goes through middle-end and BOOLEAN_TYPE.
> If assigning transfer (234, .false.) to logical is undefined behavior,
> then the only problematic case is
> integer :: i, j
> i = 234
> ...
> j = transfer (transfer (i, .false.), 0)
> (when it is non-constant).  Currently the FE expands this as
> 2 separate transfers and the optimizers will be able to see through them,
> but I'd say the FE could look through the
> transfer in the first argument and do whatever the standard requires,
> before handing it to the middle-end.  In this case change it to
> j = transfer (i, 0) (or just i).

We could, yes.  At this point, I don't think it's worth the bother (and
risk of additional bugs) of implementing it, until we get a case where
someone actually complains about it.  (And, frankly, I wish I hadn't
implemented it for the constant-folding case; as I recall, it made the
code rather a good bit more complex, and from today's perspective I
don't see the point.)

It might be useful to put something explicit into the TRANSFER
documentation pointing out the undefined behavior in the case of LOGICAL
 values for the MOLD argument, though.

- Brooks