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?
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?
Thanks,
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
