Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault

[Paul Richard Thomas <paul.richard.thomas@gmail.com>]

Hi Harald,

Well, at least you found the testcase :-)

Thanks for pointing out the obvious; ie. that I had deviated from the
original testcase. This is an important clue for some of the PRs that
come up under the "select type flag". What is surprising is that it is
gcc_assert (st->n.sym->assoc) that triggers the ICE. One would think
that the assoc field would be filled twice over.

This and the two new associate PRs that Steve pointed out have
deflated me a bit. Still, I'll press on. I will create a select-type
meta-bug when I return to my desk.

Thanks

Paul

On Sat, 17 Jun 2023 at 19:01, Harald Anlauf <anlauf@gmx.de> wrote:
>
> Hi Paul,
>
> On 6/17/23 11:14, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > The attached patch is amply described by the comments and the
> > changelog. It also includes the fix for the memory leak in decl.cc, as
> > promised some days ago.
> >
> > OK for trunk?
>
> I hate to say it, but you forgot to add the testcase again... :-(
>
> The patch fixes your "extended" testcase in
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107900#c2
>
> but the original one in comment ICEs for me here:
>
> % gfc-14 pr107900.f90
> f951: internal compiler error: Segmentation fault
> 0x1025c2f crash_signal
>          ../../gcc-trunk/gcc/toplev.cc:314
> 0x9d31d3 resolve_select_type
>          ../../gcc-trunk/gcc/fortran/resolve.cc:9791
> 0x9cef5e gfc_resolve_code(gfc_code*, gfc_namespace*)
>          ../../gcc-trunk/gcc/fortran/resolve.cc:12588
> 0x9d2431 resolve_codes
>          ../../gcc-trunk/gcc/fortran/resolve.cc:18057
> 0x9d24fe gfc_resolve(gfc_namespace*)
>          ../../gcc-trunk/gcc/fortran/resolve.cc:18092
> 0x9cf0ee gfc_resolve(gfc_namespace*)
>          ../../gcc-trunk/gcc/fortran/resolve.cc:18077
> 0x9cf0ee resolve_block_construct
>          ../../gcc-trunk/gcc/fortran/resolve.cc:10971
> 0x9cf0ee gfc_resolve_code(gfc_code*, gfc_namespace*)
>          ../../gcc-trunk/gcc/fortran/resolve.cc:12596
> 0x9d2431 resolve_codes
>          ../../gcc-trunk/gcc/fortran/resolve.cc:18057
> 0x9d24fe gfc_resolve(gfc_namespace*)
>          ../../gcc-trunk/gcc/fortran/resolve.cc:18092
> 0x9b11f1 resolve_all_program_units
>          ../../gcc-trunk/gcc/fortran/parse.cc:6864
> 0x9b11f1 gfc_parse_file()
>          ../../gcc-trunk/gcc/fortran/parse.cc:7120
> 0xa033ef gfc_be_parse_file
>          ../../gcc-trunk/gcc/fortran/f95-lang.cc:229
>
> It hits an assert here:
>
> 9790          st = gfc_find_symtree (ns->sym_root, name);
> 9791          gcc_assert (st->n.sym->assoc);
>
> My tree is slightly modified, but the changes should not have
> any effect here.
>
> Can you please have a look, too?
>
> Thanks,
> Harald
>
> > Regards
> >
> > Paul
> >
> > PS This leaves 89645 and 99065 as the only real blockers to PR87477.
> > These will take a little while to fix. They come about because the
> > type of the associate name is determined by that of a derived type
> > function that hasn't been parsed at the time that component references
> > are being parsed. If the order of the contained procedures is
> > reversed, both test cases compile correctly. The fix will comprise
> > matching the component name to the accessible derived types, while
> > keeping track of all the references in case the match is ambiguous and
> > has to be fixed up later.
>


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein