[Bug fortran/44556] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement

2010-06-17 Thread kargl at gcc dot gnu dot org 


--- Comment #5 from kargl at gcc dot gnu dot org  2010-06-17 15:22 ---
Remove [4.5/4.6 Regression] from the summary as this 
has never worked, so it can't be a regression.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.5/4.6 Regression]|incorrect error:  Stat-
   |incorrect error:  Stat- |variable at (1) shall not be
   |variable at (1) shall not be|DEALLOCATEd within the same
   |DEALLOCATEd within the same |DEALLOCATE statement
   |DEALLOCATE statement|


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556

[Bug fortran/44556] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement

2010-06-17 Thread kargl at gcc dot gnu dot org 


--- Comment #6 from kargl at gcc dot gnu dot org  2010-06-17 15:26 ---
(In reply to comment #5)
 Remove [4.5/4.6 Regression] from the summary as this 
 has never worked, so it can't be a regression.
 

Note, the OP's code appears to work in 4.4.0 because
prior to the commit noted in comment #4 there was no
checking on the constraints listed in the standard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556

[Bug fortran/44556] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement

2010-06-17 Thread kargl at gcc dot gnu dot org 


--- Comment #7 from kargl at gcc dot gnu dot org  2010-06-17 19:08 ---
The following patch restores the 4.4.0 behavior for
STAT of not checking derived type components.  This
of course now allows invalid code to compile such as
this modified version of OP's test subroutine

   subroutine test
  type(test_type) :: foo
  deallocate(foo%array, stat=foo%array(1))
   end subroutine test


Index: resolve.c
===
--- resolve.c   (revision 160935)
+++ resolve.c   (working copy)
@@ -6588,7 +6588,8 @@ resolve_allocate_deallocate (gfc_code *c
   variable, stat-where);

   for (p = code-ext.alloc.list; p; p = p-next)
-   if (p-expr-symtree-n.sym-name == stat-symtree-n.sym-name)
+   if (stat-symtree-n.sym-ts.type != BT_DERIVED
+p-expr-symtree-n.sym-name == stat-symtree-n.sym-name)
  gfc_error (Stat-variable at %L shall not be %sd within 
 the same %s statement, stat-where, fcn, fcn);
 }
@@ -6617,7 +6618,8 @@ resolve_allocate_deallocate (gfc_code *c
   variable, errmsg-where);

   for (p = code-ext.alloc.list; p; p = p-next)
-   if (p-expr-symtree-n.sym-name == errmsg-symtree-n.sym-name)
+   if (errmsg-symtree-n.sym-ts.type != BT_DERIVED
+p-expr-symtree-n.sym-name == errmsg-symtree-n.sym-name)
  gfc_error (Errmsg-variable at %L shall not be %sd within 
 the same %s statement, errmsg-where, fcn, fcn);
 }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556

[Bug fortran/44556] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement

2010-06-17 Thread burnus at gcc dot gnu dot org 


--- Comment #8 from burnus at gcc dot gnu dot org  2010-06-17 23:13 ---
Created an attachment (id=20935)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20935action=view)
Draft patch, which keeps diagnostic for derived types

Draft patch, which fixes this regression and also adds a check for component
access. Not yet regtested.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556