| Summary: | [4.3 Regression] PRIVATE variable not allowed as STAT variable in ALLOCATE | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Dick Hendrickson <dick.hendrickson> |
| Component: | fortran | Assignee: | Tobias Burnus <burnus> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gcc-bugs |
| Priority: | P3 | Keywords: | rejects-valid |
| Version: | 4.3.0 | ||
| Target Milestone: | --- | ||
| 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 |
| Bug Depends on: | |||
| Bug Blocks: | 32834 | ||
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. 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;
I have a patch, which needs to be regression tested. Watch this place! 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 FIXED on the trunk (4.3.0). Thanks for the bug report. |
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