On Fri, Feb 29, 2008 at 1:01 PM, FX <[EMAIL PROTECTED]> 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.
