Bug 42008 - Wrongly rejected derived types with default initializers in PURE procedures
Wrongly rejected derived types with default initializers in PURE procedures
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.5.0
: P3 normal
: ---
Assigned To: Jerry DeLisle
: rejects-valid
: 42016 (view as bug list)
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2009-11-11 11:17 UTC by Tobias Burnus
Modified: 2009-11-26 03:26 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-11-22 18:47:44


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2009-11-11 11:17:21 UTC
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/141265154c2fcc71

Reinhold Bader thinks that at least the second program, using default initializers, is valid. Oddly, the program works with the TYPE is not defined locally but use-associated.

The first program of M. Restelli is presumably wrong as it uses variables which are implicitly declared as SAVE. - But one should re-check.


ifort v11.1, NAG f95 v5.1, pathscale 3.3b all accept all programs, g95 and gfortran reject "one" and "two (B)".


!------ Program one ----------
module mod_xyz
 implicit none
contains
 pure subroutine psub()
  type ilist
    type(ilist), pointer :: next => null()
    integer :: i
  end type ilist
 end subroutine psub
end module mod_xyz
!------------------

!---------- Program two (A) ----------
module mod_xyz
 implicit none
 type ilist
   type(ilist), pointer :: next => null()
   integer :: i
 end type ilist
contains
 pure subroutine psub()
  type(ilist) :: var ! ACCEPTED
 end subroutine psub
end module mod_xyz

!---------- Program two (B) ----------
module mod_xyz2
 implicit none
contains
 pure subroutine psub()
  type ilist
    type(ilist), pointer :: next => null()
    integer :: i
  end type ilist
  type(ilist) :: var ! REJECTED
 end subroutine psub
end module mod_xyz2
!---------------------------------
Comment 1 Tobias Burnus 2009-11-11 12:54:44 UTC
Misread the program one. I think it is also valid.

The constraint which is wrongly applied is:

"C1268 A local variable declared in the specification-part or internal-subprogram-part of a pure subprogram shall not have the SAVE attribute."

I could not find any (other) relevant constraint in "12.6 Pure procedures".
Comment 2 Tobias Burnus 2009-11-12 11:21:17 UTC
*** Bug 42016 has been marked as a duplicate of this bug. ***
Comment 3 Jerry DeLisle 2009-11-23 03:06:29 UTC
This appears to fix this with no regressions.  I will commit as obvious tomorrow.

Index: decl.c
===================================================================
--- decl.c	(revision 154430)
+++ decl.c	(working copy)
@@ -1865,13 +1865,6 @@ variable_decl (int elem)
 	      m = MATCH_ERROR;
 	    }
 
-	  if (gfc_pure (NULL))
-	    {
-	      gfc_error ("Initialization of pointer at %C is not allowed in "
-			 "a PURE procedure");
-	      m = MATCH_ERROR;
-	    }
-
 	  if (m != MATCH_YES)
 	    goto cleanup;
 
Comment 4 Tobias Burnus 2009-11-23 12:38:07 UTC
Does your patch still reject

pure function test()
  integer, pointer :: p => null() ! INVALID per C1272
  integer :: test
  test = p
end function test

That is currently rejected as "Error: Initialization of pointer at (1) is not allowed in a PURE procedure".

NAG f95 rejects it with:
  "ERROR: Local variable P of PURE procedure TEST has the SAVE attribute"
as "p" gets implicitly declared as SAVE. There might well be a check for it in gfortran already, but seemingly no test case.

If there is no such test case, could you also add it?
Comment 5 Jerry DeLisle 2009-11-23 13:44:36 UTC
Without the patch it is rejected, with the patch it is not.  I will look into this further.
Comment 6 Tobias Burnus 2009-11-23 19:35:18 UTC
(In reply to comment #5)
> Without the patch it is rejected, with the patch it is not.  I will look into
> this further.

Would something like  "if (...->attr.saved) { gfc_error }" work, combined with the patch from comment 3?

Comment 7 Jerry DeLisle 2009-11-24 04:32:14 UTC
This seems to do the trick:

Index: decl.c
===================================================================
--- decl.c	(revision 154430)
+++ decl.c	(working copy)
@@ -1865,7 +1865,7 @@ variable_decl (int elem)
 	      m = MATCH_ERROR;
 	    }
 
-	  if (gfc_pure (NULL))
+	  if (gfc_pure (NULL) && gfc_state_stack->state != COMP_DERIVED)
 	    {
 	      gfc_error ("Initialization of pointer at %C is not allowed in "
 			 "a PURE procedure");


None of the examples have any save attributes set, implied or otherwise.  This patch allows the initial three examples and rejects the example in comment #4. Is this what we are looking for?
Comment 8 Tobias Burnus 2009-11-24 06:59:04 UTC
(In reply to comment #7)
> +         if (gfc_pure (NULL) && gfc_state_stack->state != COMP_DERIVED)

Looks OK.

> None of the examples have any save attributes set, implied or otherwise.

Probably not in decl.c - but at some point, it should get that status as
  foo = init-expr
and
  fooptr => init-expr
implies SAVE. (Actually, the implied SAVE seems to works as expected - I just checked for pointer.)
Comment 9 Jerry DeLisle 2009-11-25 02:41:35 UTC
Subject: Bug 42008

Author: jvdelisle
Date: Wed Nov 25 02:41:20 2009
New Revision: 154530

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154530
Log:
2009-11-24  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/42008
	* gfortran.dg/pure_initializer_2.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/pure_initializer_2.f90
Modified:
    trunk/gcc/testsuite/ChangeLog

Comment 10 Jerry DeLisle 2009-11-25 02:42:36 UTC
Subject: Bug 42008

Author: jvdelisle
Date: Wed Nov 25 02:42:22 2009
New Revision: 154531

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154531
Log:
2009-11-24  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/42008
	* decl.c (variable_decl): Do not error on initialization within a
	derived type specification of a pure procedure.

Modified:
    trunk/gcc/fortran/ChangeLog

Comment 11 Jerry DeLisle 2009-11-25 02:43:31 UTC
I messed up the PR Number again.  The commit for above was:

Transmitting file data ..
Committed revision 154529.
Comment 12 Tobias Burnus 2009-11-25 13:21:20 UTC
(In reply to comment #11)
> I messed up the PR Number again.  The commit for above was:

http://gcc.gnu.org/viewcvs?view=revision&revision=154529

2009-11-24  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/41807
	* decl.c (variable_decl): Do not error on initialization within a
	derived type specification of a pure procedure.

 * * *

Can this PR now be closed as fixed? Or do you want to backport it to 4.4?
Comment 13 Jerry DeLisle 2009-11-26 03:26:13 UTC
Fixed on mainline.