Bug 34760 - [4.3 Regression] PRIVATE variable not allowed as STAT variable in ALLOCATE
Summary: [4.3 Regression] PRIVATE variable not allowed as STAT variable in ALLOCATE
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Tobias Burnus
URL:
Keywords: rejects-valid
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-01-12 20:23 UTC by Dick Hendrickson
Modified: 2008-01-19 17:13 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work: 4.2.2 4.1.3
Known to fail: 4.3.0
Last reconfirmed: 2008-01-17 22:32:20


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Hendrickson 2008-01-12 20:23:03 UTC
With gfortran 4.3.0 20080109 I get the error message

     ALLOCATE (RLA1(NF10), STAT = ISTAT)
                                      1
Error: STAT expression at (1) must be a variable

With the following program.

     MODULE TESTS
     INTEGER, PRIVATE :: ISTAT       !this one FAILS
!      INTEGER :: ISTAT               !this one works
!      PRIVATE :: ISTAT               !this one FAILS
     CONTAINS
     SUBROUTINE AD0001
     REAL RLA1(:)
     ALLOCATABLE RLA1
     ISTAT = -314
     ALLOCATE (RLA1(NF10), STAT = ISTAT)
     END SUBROUTINE
     END MODULE

In the real module there are several subroutines that do similar
allocates and they do not generate the error.  It looks like it is
only the first use of ISTAT in an allocate that triggers the message.

Dick Hendrickson
Comment 1 Tobias Burnus 2008-01-12 22:49:33 UTC
DEALLOCATE has actually the same problem.

Regarding gfc_match_allocate/gfc_match_deallocate:
a) "if (stat->symtree->n.sym->attr.flavor != FL_VARIABLE)" is false as the flavor is FL_UNKNOWN.
b) ALLOCATE has much more checks for "stat" being a variable than DEALLOCATE, I had expected that they have the same checks for STAT.
Comment 2 Tobias Burnus 2008-01-13 22:49:48 UTC
match_variable is called for "istat" in the subroutine. For the first match, it is FL_UNKNOWN and then - without PRIVATE - it is set to FL_VARIABLE. With public/private, it remains FL_UNKNOWN.

As for ALLOCATE sym->attr.flavor == FL_VARIABLE is check, it fails therefore as soon as the variable has been marked as public/private.

match_variable contains:

  switch (sym->attr.flavor)
    {
[...]
    case FL_UNKNOWN:
      if (sym->attr.access == ACCESS_PUBLIC
          || sym->attr.access == ACCESS_PRIVATE)
        break;
      if (gfc_add_flavor (&sym->attr, FL_VARIABLE,
                          sym->name, NULL) == FAILURE)
        return MATCH_ERROR;
      break;
Comment 3 Tobias Burnus 2008-01-13 22:57:22 UTC
Regression, caused by the fix for PR 32760.
Comment 4 Tobias Burnus 2008-01-17 22:32:20 UTC
I have a patch, which needs to be regression tested. Watch this place!
Comment 5 Tobias Burnus 2008-01-19 14:16:50 UTC
Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00236.html
Comment 6 Tobias Burnus 2008-01-19 15:41:50 UTC
Subject: Bug 34760

Author: burnus
Date: Sat Jan 19 15:41:04 2008
New Revision: 131652

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131652
Log:
2008-01-19  Tobias Burnus  <burnus@net-b.de>

        PR fortran/34760
        * primary.c (match_variable): Handle FL_UNKNOWN without
        uneducated guessing.
        (match_variable): Improve error message.

2008-01-19  Tobias Burnus  <burnus@net-b.de>

        PR fortran/34760
        * gfortran.dg/implicit_11.f90: New.
        * gfortran.dg/allocate_stat.f90: Update dg-error pattern.
        * gfortran.dg/entry_15.f90: Ditto.
        * gfortran.dg/func_assign.f90: Ditto.
        * gfortran.dg/gomp/reduction3.f90: Ditto.
        * gfortran.dg/proc_assign_1.f90: Ditto.

        * gfortran.dg/interface_proc_end.f90: Use dg-error instead
        of dg-excess-errors.


Added:
    trunk/gcc/testsuite/gfortran.dg/implicit_11.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/primary.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/allocate_stat.f90
    trunk/gcc/testsuite/gfortran.dg/entry_15.f90
    trunk/gcc/testsuite/gfortran.dg/func_assign.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/reduction3.f90
    trunk/gcc/testsuite/gfortran.dg/interface_proc_end.f90
    trunk/gcc/testsuite/gfortran.dg/proc_assign_1.f90

Comment 7 Tobias Burnus 2008-01-19 17:13:04 UTC
FIXED on the trunk (4.3.0).

Thanks for the bug report.