Le 28/07/2024 à 11:24, Paul Richard Thomas a écrit :
I have attached the updated and rather simpler patch.
OK for master and backport.
Thanks for the patch.
Thanks for the prod, Mikael!
Paul
Fortran: Fix ICE with structure constructor in data statement [PR79685]
2024-07-28 Paul Thomas <pa...@gcc.gnu.org <mailto:pa...@gcc.gnu.org>>
gcc/fortran
PR fortran/79685
* decl.cc (match_data_constant): Find the symtree instead of
the symbol so the use renamed symbols are found. Pass this and
the derived type to gfc_match_structure_constructor.
* match.h: Update prototype of gfc_match_structure_contructor.
* primary.cc (gfc_match_structure_constructor): Remove call to
gfc_get_ha_sym_tree and use caller supplied symtree instead.
gcc/testsuite/
PR fortran/79685
* gfortran.dg/use_rename_12.f90: New test.
On Sat, 27 Jul 2024 at 22:04, Paul Richard Thomas
<paul.richard.tho...@gmail.com <mailto:paul.richard.tho...@gmail.com>>
wrote:
Hi Mikael,
You were absolutely right. I looked at the caller and "just didn't
get it". Thanks. I will resubmit when I get back from a business trip.
Cordialement
Paul
On Sat, 27 Jul 2024 at 12:35, Mikael Morin <morin-mik...@orange.fr
<mailto:morin-mik...@orange.fr>> wrote:
Hello,
Le 27/07/2024 à 11:25, Paul Richard Thomas a écrit :
> This patch is straightforward but I am still puzzled as to
why it is
> necessary for the particular case. Having looked at all the
other chunks
> of frontend code involving use renaming, it seems that the
process just
> works everywhere else. I tried putting the new code in
gfc_find_symtree
> but it caused some regressions unless I pinned it down to the
specific
> case of a structure constructor.
>
I think it works as expected, symtrees have the local names, and
symbols
the original name, so if all that is available is the symbol, name
lookup may not work correctly with renaming. And I think that
there are
other places where it happens.
In this case, it seems the caller can provide the local name, which
would avoid processing the use statements. Did you try that?
Mikael