[Bug fortran/94397] New: [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error.

[Bug fortran/94397] New: [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error.

[chinoune.mehdi at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

            Bug ID: 94397
           Summary: [10 Regression] the compiler consider "type is(
                    real(kind(1.)) )" as a syntax error.
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chinoune.mehdi at hotmail dot com
  Target Milestone: ---

Failed to build https://github.com/Goddard-Fortran-Ecosystem/pFUnit (which I
successfully built last Monday 23-03-2020) this morning with gcc-git.
This is the reduced code:

$ cat type_is.f90
module m
  implicit none
contains
  subroutine sub(a)
    class(*) :: a
    select type(a)
      type is ( real( kind(1.) ) )
        a = 1.
    end select
  end subroutine sub
end module m

$ gfortran-10 -c type_is.f90
type_is.f90:7:32:

    7 |       type is ( real( kind(1.) ) )
      |                                1
Error: Syntax error in TYPE IS specification at (1)
type_is.f90:8:14:

    8 |         a = 1.
      |              1
Error: Expected TYPE IS, CLASS IS or END SELECT statement following SELECT TYPE
at (1)

$gfortran-10 --version
GNU Fortran (GCC) 10.0.1 20200330 (experimental)

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
   Target Milestone|---                         |10.0
           Priority|P3                          |P4

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error.

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |10.0
     Ever confirmed|0                           |1
                 CC|                            |markeggleston at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |9.3.0
   Last reconfirmed|                            |2020-03-30

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r10-7369-gc38daa7976886a59.

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Martin Liška from comment #1)
> Confirmed, started with r10-7369-gc38daa7976886a59.

Patch in the linked git revision appears to expose a latent
bug in TYPE IS().   Two workarounds are to use either

type is (real(4))  ! Bad, because of hard coded kind parameter

or

integer, parameter :: sp = kind(1.)
...
type is (real(sp))

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Mar 30, 2020 at 04:23:11PM +0000, kargl at gcc dot gnu.org wrote:
> 
> --- Comment #2 from kargl at gcc dot gnu.org ---
> (In reply to Martin Liška from comment #1)
> > Confirmed, started with r10-7369-gc38daa7976886a59.
> 
> Patch in the linked git revision appears to expose a latent
> bug in TYPE IS().   Two workarounds are to use either
> 
> type is (real(4))  ! Bad, because of hard coded kind parameter
> 
> or
> 
> integer, parameter :: sp = kind(1.)
> ...
> type is (real(sp))
> 

Untested patch against svn reverion 280157.

Index: gcc/fortran/match.c
===================================================================
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -2239,7 +2239,8 @@ found:
         a scalar integer initialization-expr and valid kind parameter. */
       if (c == ')')
        {
-         if (e->ts.type != BT_INTEGER || e->rank > 0)
+         if (!gfc_reduce_init_expr (e)
+             || e->ts.type != BT_INTEGER || e->rank > 0)
            {
              gfc_free_expr (e);
              return MATCH_NO;

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[markeggleston at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

--- Comment #4 from markeggleston at gcc dot gnu.org ---
The compilation error reported is due this change in PR93484:

--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -2222,9 +2222,9 @@ gfc_match_type_spec (gfc_typespec *ts)

 found:

-      m = gfc_match_init_expr (&e);
+      m = gfc_match_expr (&e);

Changing it back causes test cases ISO_Fortran_binding_11.f90 and pr78033.f90
to fail.

If "kind=" is found gfc_match_init_expr (&e) should be used and when it is not
gfc_match_expr (&e).

I'm checking a suitable test case and will have a patch ready soon.

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to markeggleston from comment #4)
> The compilation error reported is due this change in PR93484:
> 
> --- a/gcc/fortran/match.c
> +++ b/gcc/fortran/match.c
> @@ -2222,9 +2222,9 @@ gfc_match_type_spec (gfc_typespec *ts)
>  
>  found:
>  
> -      m = gfc_match_init_expr (&e);
> +      m = gfc_match_expr (&e);
> 
> Changing it back causes test cases ISO_Fortran_binding_11.f90 and
> pr78033.f90 to fail.
> 
> If "kind=" is found gfc_match_init_expr (&e) should be used and when it is
> not gfc_match_expr (&e).
> 
> I'm checking a suitable test case and will have a patch ready soon.

The patch in comment #3 likely is the correct patch.  When in the
specification part of a scoping unit, the above change is needed to
distinguish REAL(kind(1.)) from REAL(1.1, kind(1.)).  In the former,
we have a type and kind(1.) must be an initialization expression
(see comment 3 or 4 lines down).  In the latter case, we have the
intrinsic subprogram, and simply return MATCH_NO or MATCH_ERROR.

-- 
steve

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[markeggleston at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

--- Comment #6 from markeggleston at gcc dot gnu.org ---
(In reply to kargl from comment #5)
> (In reply to markeggleston from comment #4)
> > The compilation error reported is due this change in PR93484:
> > 
> > --- a/gcc/fortran/match.c
> > +++ b/gcc/fortran/match.c
> > @@ -2222,9 +2222,9 @@ gfc_match_type_spec (gfc_typespec *ts)
> >  
> >  found:
> >  
> > -      m = gfc_match_init_expr (&e);
> > +      m = gfc_match_expr (&e);
> > 
> > Changing it back causes test cases ISO_Fortran_binding_11.f90 and
> > pr78033.f90 to fail.
> > 
> > If "kind=" is found gfc_match_init_expr (&e) should be used and when it is
> > not gfc_match_expr (&e).
> > 
> > I'm checking a suitable test case and will have a patch ready soon.
> 
> The patch in comment #3 likely is the correct patch.  When in the
> specification part of a scoping unit, the above change is needed to
> distinguish REAL(kind(1.)) from REAL(1.1, kind(1.)).  In the former,
> we have a type and kind(1.) must be an initialization expression
> (see comment 3 or 4 lines down).  In the latter case, we have the
> intrinsic subprogram, and simply return MATCH_NO or MATCH_ERROR.
> 
> -- 
> steve

Thanks Steve.  Should've tried your patch earlier, it is much simpler than mine
and I've verified that it works. There was a nagging feeling that my solution
was incomplete. I'm happy to add test cases to your patch and send it upstream
for approval.

[Bug fortran/94397] [9/10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to markeggleston from comment #6)
> Thanks Steve.  Should've tried your patch earlier, it is much simpler than
> mine and I've verified that it works. There was a nagging feeling that my
> solution was incomplete. I'm happy to add test cases to your patch and send
> it upstream for approval.
Any progress?

[Bug fortran/94397] [9/10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[markeggleston at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

--- Comment #8 from markeggleston at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> (In reply to markeggleston from comment #6)
> > Thanks Steve.  Should've tried your patch earlier, it is much simpler than
> > mine and I've verified that it works. There was a nagging feeling that my
> > solution was incomplete. I'm happy to add test cases to your patch and send
> > it upstream for approval.
> Any progress?

Unfortunately I was diverted on to working on something else and when I got
back to it I found that two test case failures occurred: pr93484_1.f90 and
pr93484_2.f90 both failing with ICE.  These did not occur when I last checked
the patch.

Thanks for the nudge, I intend to fully investigate today.

[Bug fortran/94397] [9/10/11 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.0                        |10.2

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.1 has been released.

[Bug fortran/94397] [9/10/11 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mark Eggleston
<markeggleston@gcc.gnu.org>:

https://gcc.gnu.org/g:3ea6977d0f1813d982743a09660eec1760e981ec

commit r11-693-g3ea6977d0f1813d982743a09660eec1760e981ec
Author: Mark Eggleston <markeggleston@gcc.gnu.org>
Date:   Wed Apr 1 09:52:41 2020 +0100

    Fortran  : "type is( real(kind(1.)) )" spurious syntax error PR94397

    Based on a patch in the comments of the PR. That patch fixed this
    problem but caused the test cases for PR93484 to fail. It has been
    changed to reduce initialisation expressions if the expression is
    not EXPR_VARIABLE and not EXPR_CONSTANT.

    2020-05-28  Steven G. Kargl  <kargl@gcc.gnu.org>
                Mark Eggleston  <markeggleston@gcc.gnu.org>

    gcc/fortran/

            PR fortran/94397
            * match.c (gfc_match_type_spec): New variable ok initialised
            to true. Set ok with the return value of gfc_reduce_init_expr
            called only if the expression is not EXPR_CONSTANT and is not
            EXPR_VARIABLE. Add !ok to the check for type not being integer
            or the rank being greater than zero.

    2020-05-28  Mark Eggleston  <markeggleston@gcc.gnu.org>

    gcc/testsuite/

            PR fortran/94397
            * gfortran.dg/pr94397.F90: New test.

[Bug fortran/94397] [9/10/11 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Mark Eggleston
<markeggleston@gcc.gnu.org>:

https://gcc.gnu.org/g:f2fe2ad8d379297dcf571b2b9c46200c5ae5391f

commit r10-8200-gf2fe2ad8d379297dcf571b2b9c46200c5ae5391f
Author: Mark Eggleston <markeggleston@gcc.gnu.org>
Date:   Wed Apr 1 09:52:41 2020 +0100

    Fortran  : "type is( real(kind(1.)) )" spurious syntax error PR94397

    Based on a patch in the comments of the PR. That patch fixed this
    problem but caused the test cases for PR93484 to fail. It has been
    changed to reduce initialisation expressions if the expression is
    not EXPR_VARIABLE and not EXPR_CONSTANT.

    2020-05-28  Steven G. Kargl  <kargl@gcc.gnu.org>
                Mark Eggleston  <markeggleston@gcc.gnu.org>

    gcc/fortran/

            PR fortran/94397
            * match.c (gfc_match_type_spec): New variable ok initialised
            to true. Set ok with the return value of gfc_reduce_init_expr
            called only if the expression is not EXPR_CONSTANT and is not
            EXPR_VARIABLE. Add !ok to the check for type not being integer
            or the rank being greater than zero.

    2020-05-28  Mark Eggleston  <markeggleston@gcc.gnu.org>

    gcc/testsuite/

            PR fortran/94397
            * gfortran.dg/pr94397.F90: New test.

    (cherry picked from commit 3ea6977d0f1813d982743a09660eec1760e981ec)

[Bug fortran/94397] [9/10/11 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Mark Eggleston
<markeggleston@gcc.gnu.org>:

https://gcc.gnu.org/g:e211b3da3899b3496add56ba45acb07569e7c15a

commit r9-8632-ge211b3da3899b3496add56ba45acb07569e7c15a
Author: Mark Eggleston <markeggleston@gcc.gnu.org>
Date:   Wed Apr 1 09:52:41 2020 +0100

    Fortran  : "type is( real(kind(1.)) )" spurious syntax error PR94397

    Based on a patch in the comments of the PR. That patch fixed this
    problem but caused the test cases for PR93484 to fail. It has been
    changed to reduce initialisation expressions if the expression is
    not EXPR_VARIABLE and not EXPR_CONSTANT.

    2020-05-28  Steven G. Kargl  <kargl@gcc.gnu.org>
                Mark Eggleston  <markeggleston@gcc.gnu.org>

    gcc/fortran/

            PR fortran/94397
            * match.c (gfc_match_type_spec): New variable ok initialised
            to true. Set ok with the return value of gfc_reduce_init_expr
            called only if the expression is not EXPR_CONSTANT and is not
            EXPR_VARIABLE. Add !ok to the check for type not being integer
            or the rank being greater than zero.

    2020-05-28  Mark Eggleston  <markeggleston@gcc.gnu.org>

    gcc/testsuite/

            PR fortran/94397
            * gfortran.dg/pr94397.F90: New test.

    (cherry picked from commit 3ea6977d0f1813d982743a09660eec1760e981ec)

[Bug fortran/94397] [9/10/11 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[markeggleston at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397

markeggleston at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from markeggleston at gcc dot gnu.org ---
committed to master and backported