Re: Some help with fold_convert() on RECORD_TYPEs

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Fri, Feb 29, 2008 at 1:01 PM, FX <fxcoudert@gmail.com> wrote:
> Hi all,
>
>  I'm going forward on my patch to remove the multiple decls emitted by
>  the Fortran front-end for a single function. The problem is that doing
>  so yields quite a few type mismatch issues that were hidden by it.
>  Some of them can be corrected in the front-end, and for some of them I
>  just don't know. Today's example is an error when we try to
>  fold_convert() a RECORD_TYPE into a different, but similar
>  RECORD_TYPE. Namely, the right hand side is:
>
>  (gdb) p debug_tree(rse->expr)
>   <call_expr 0x2b87100be870
>     type <record_type 0x2b8710158000 t SI
>         size <integer_cst 0x2b87100baa50 constant invariant 32>
>         unit size <integer_cst 0x2b87100ba6c0 constant invariant 4>
>         align 32 symtab 0 alias set -1 canonical type 0x2b8710158000
>         fields <field_decl 0x2b8710153aa0 i type <integer_type
>  0x2b87100c7540 integer(kind=4)>
>             SI file a2.f90 line 3 col 0 size <integer_cst
>  0x2b87100baa50 32> unit size <integer_cst 0x2b87100ba6c0 4>
>             align 32 offset_align 128
>             offset <integer_cst 0x2b87100ba6f0 constant invariant 0>
>             bit offset <integer_cst 0x2b87100baf30 constant invariant
>  0> context <record_type 0x2b8710158000 t>>
>         chain <type_decl 0x2b87101580c0 D.901>>
>     [...]
>
>  and the left hand side is:
>
>  (gdb) p debug_tree(lse->expr)
>   <var_decl 0x2b8710153f00 res
>     type <record_type 0x2b8710158480 t SI
>         size <integer_cst 0x2b87100baa50 constant invariant 32>
>         unit size <integer_cst 0x2b87100ba6c0 constant invariant 4>
>         align 32 symtab 0 alias set -1 canonical type 0x2b8710158480
>         fields <field_decl 0x2b8710153e60 i type <integer_type
>  0x2b87100c7540 integer(kind=4)>
>             SI file a2.f90 line 11 col 0 size <integer_cst
>  0x2b87100baa50 32> unit size <integer_cst 0x2b87100ba6c0 4>
>             align 32 offset_align 128
>             offset <integer_cst 0x2b87100ba6f0 constant invariant 0>
>             bit offset <integer_cst 0x2b87100baf30 constant invariant
>  0> context <record_type 0x2b8710158480 t>>
>         chain <type_decl 0x2b8710158540 D.907>>
>     [...]
>
>  The two record types are equivalent in Fortran rules: in Fortran, you
>  can assign between two different type (defined in different places, or
>  with different names) as long as they have the same list of
>  components, in the same order, with the same attributes. However, the
>  middle-end doesn't like that, and fold_convert'ing rse->expr into a
>  TREE_TYPE(lse->expr) yields to failure. My questions are:
>
>   1. Is this limitation in the middle-end likely to be lifted if we
>  ask nicely? I mean, if I understand correctly, the current behaviour
>  is implemented here because it's the right thing to do to support C,
>  but GCC is more than C, so maybe it could be considered to change this
>  assumption? Or would that be more work than I imagine?

Sort of.  The frontend is supposed to note this compatibility via
the TYPE_MAIN_VARIANT or the TYPE_CANONICAL mechanism
(note that fold_convert doesn't listen to TYPE_CANONICAL at all
at the moment, but this eventually needs to change anyway).

>   2. Could a Fortran maintainer who knows copy_dt_decls_ifequal()
>  advise me on how likely it is that we can resolve this directly in the
>  front-end? For example, I imagine we could, before building a new type
>  node, go through all the other derived types nodes and see if there's
>  one that fits... but is that a reasonable thing to do? Or would it
>  break other stuff that I don't think off?

Another workaround is to use a VIEW_CONVERT_EXPR in case
fold_convertible_p () returns false but you still think you are ok.

Richard.