diff mbox series

[fortran] PR98897 - Erroneous procedure attribute for associate name

Message ID CAGkQGiKSobUg=WtUHv8UHgHeLM5_3kPLBSmzWV4CzG0808KU7w@mail.gmail.com
State New
Headers show
Series [fortran] PR98897 - Erroneous procedure attribute for associate name | expand

Commit Message

Paul Richard Thomas Feb. 2, 2021, 12:20 p.m. UTC 
This is more or less 'obvious' and does not require any further explanation.

Regtests with FC33/x86_64 - OK for master (and ....)?

Paul

Fortran: Fix calls to associate name typebound subroutines [PR98897].

2021-02-02  Paul Thomas  <pault@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.

Comments

Tobias Burnus Feb. 2, 2021, 1:59 p.m. UTC | #1 
Hi Paul,

On 02.02.21 13:20, Paul Richard Thomas via Gcc-patches wrote:
> This is more or less 'obvious' and does not require any further explanation.

Well, I am not sure whether calling resolve is premature or not. In any
case, it still fails for the attached testcase. (Related but separate
issue.)

The second testcase fails with "Selector at (1) has no type" / "Symbol
'var' at (1) has no IMPLICIT type".

Disclaimer: I am not 100% sure whether those two or your/the PR's
testcase is valid. (It fails to compile with ifort 19.1. I have not read
the spec and assume that the original testcase is valid.)

Thus, please confirm that all three are valid. If so, do you see a way
to make the two new ones pass as well? If we are sure that the current
patch is still the right approach, I am also fine to do it stepwise.

Thanks,

Tobias

> Regtests with FC33/x86_64 - OK for master (and ....)?
>
> Paul
>
> Fortran: Fix calls to associate name typebound subroutines [PR98897].
>
> 2021-02-02  Paul Thomas  <pault@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
Paul Richard Thomas Feb. 2, 2021, 3:05 p.m. UTC | #2 
Hi Tobias,

ifort (IFORT) 2021.1 Beta 20201112 is happy with the testcase in the patch.

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
ifort complains:
../pr98897/foo.f90(11): error #8179: The procedure pointer and the
procedure target must both be functions or subroutines.
    res => double

The responses from both compilers to foo3.f90 are the same.

Cheers

Paul



On Tue, 2 Feb 2021 at 13:59, Tobias Burnus <tobias@codesourcery.com> wrote:

> Hi Paul,
>
> On 02.02.21 13:20, Paul Richard Thomas via Gcc-patches wrote:
> > This is more or less 'obvious' and does not require any further
> explanation.
>
> Well, I am not sure whether calling resolve is premature or not. In any
> case, it still fails for the attached testcase. (Related but separate
> issue.)
>
> The second testcase fails with "Selector at (1) has no type" / "Symbol
> 'var' at (1) has no IMPLICIT type".
>
> Disclaimer: I am not 100% sure whether those two or your/the PR's
> testcase is valid. (It fails to compile with ifort 19.1. I have not read
> the spec and assume that the original testcase is valid.)
>
> Thus, please confirm that all three are valid. If so, do you see a way
> to make the two new ones pass as well? If we are sure that the current
> patch is still the right approach, I am also fine to do it stepwise.
>
> Thanks,
>
> Tobias
>
> > Regtests with FC33/x86_64 - OK for master (and ....)?
> >
> > Paul
> >
> > Fortran: Fix calls to associate name typebound subroutines [PR98897].
> >
> > 2021-02-02  Paul Thomas  <pault@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
>
Tobias Burnus Feb. 2, 2021, 3:56 p.m. UTC | #3 
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 <tobias@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  <pault@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
Paul Richard Thomas Feb. 12, 2021, 1:36 p.m. UTC | #4 
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 <tobias@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 <tobias@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  <pault@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
>
diff mbox series

Patch

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index f0469e25da6..2df6191d7e6 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -4999,10 +4999,16 @@  gfc_match_call (void)
   sym = st->n.sym;
 
   /* If this is a variable of derived-type, it probably starts a type-bound
-     procedure call.  */
-  if ((sym->attr.flavor != FL_PROCEDURE
-       || gfc_is_function_return_value (sym, gfc_current_ns))
-      && (sym->ts.type == BT_DERIVED || sym->ts.type == BT_CLASS))
+     procedure call. Associate variable targets have to be resolved for the
+     target type.  */
+  if (((sym->attr.flavor != FL_PROCEDURE
+	|| gfc_is_function_return_value (sym, gfc_current_ns))
+       && (sym->ts.type == BT_DERIVED || sym->ts.type == BT_CLASS))
+		||
+      (sym->assoc && sym->assoc->target
+       && gfc_resolve_expr (sym->assoc->target)
+       && (sym->assoc->target->ts.type == BT_DERIVED
+	   || sym->assoc->target->ts.type == BT_CLASS)))
     return match_typebound_call (st);
 
   /* If it does not seem to be callable (include functions so that the