Hi All,
Following off-list discussion with Tobias, I have committed the patch as
submitted to 10- and 11-branches.
A rather general problem with parsing and matching, which arose from the
discussion, has been shunted into PR99065. If possible, I intend to fix
this by two pass parsing/matching of all contained procedures; first all
specification blocks and then, on the second pass, the code blocks. This
should eliminate the need for the likes of
parse.c(gfc_fixup_sibling_symbols) and some similar fixups in resolve.c.
Regards
Paul
On Tue, 2 Feb 2021 at 15:56, Tobias Burnus <tob...@codesourcery.com> wrote:
> Hi,
>
> first, I have attached a new example – it works if I move bar/hello up,
> but if 'foo' comes first, it fails. I think it is valid.
> (ifort 19 also compiles it.)
>
> Sorry for trying hard to find examples where it does not
> work – but I have simply the feeling that resolving things
> during parsing cannot work in all cases.
>
> On the other hand, I think your patch at least does not break
> valid code as I had feared before. :-)
> Thus, in that sense it would work for me.
>
> * * *
>
> Regarding my previous examples, they are invalid because of:
>
> C1105 (R1105) expr shall not be a designator of a procedure pointer
> or a function reference that returns a procedure pointer.
>
> However:
>
> On 02.02.21 16:05, Paul Richard Thomas via Fortran wrote:
>
> > In foo.f90, if I remove
> > call var(i) ! { dg-bogus "VARIABLE attribute of 'var' conflicts
> with
> > PROCEDURE attribute" }
> > gfortran correctly complains
> > 23 | associate (var => bar())
> > | 1
> > Error: Selector at (1) has no type
>
> Which is not quite right. bar() has a type – it returns
> a procedure pointer; even in cases where gfortran could
> know at parse time, it does not diagnose C1105 but shows
> an odd error instead.
>
> > ifort complains:
> > ../pr98897/foo.f90(11): error #8179: The procedure pointer and the
> > procedure target must both be functions or subroutines.
> > res => double
> Okay, we found a bug in ifort. 'double' and 'res' have the same
> interface by construction – and both are subroutines.
> It seems to be a similar bug to the ifort bug I got before:
> When 'double' is parsed, ifort expects that 'precision' follows
> ('double precision').
>
> > The responses from both compilers to foo3.f90 are the same.
>
> (I forgot to comment/remove 'procedure(bar) :: var' when
> playing around.) Again, this code violates C1105 – and the
> error messages are still odd.
>
> > On Tue, 2 Feb 2021 at 13:59, Tobias Burnus <tob...@codesourcery.com>
> wrote:
> > On 02.02.21 13:20, Paul Richard Thomas via Gcc-patches wrote:
> >>> Regtests with FC33/x86_64 - OK for master (and ....)?
> >>> Fortran: Fix calls to associate name typebound subroutines [PR98897].
> >>>
> >>> 2021-02-02 Paul Thomas <pa...@gcc.gnu.org>
> >>>
> >>> gcc/fortran
> >>> PR fortran/98897
> >>> * match.c (gfc_match_call): Include associate names as possible
> >>> entities with typebound subroutines. The target needs to be
> >>> resolved for the type.
> >>>
> >>> gcc/testsuite/
> >>> PR fortran/98897
> >>> * gfortran.dg/typebound_call_32.f90: New test.
> -----------------
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
> Thürauf
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
