[Patch, Fortran, F08] PR 45290: pointer initialization

[Patch, Fortran, F08] PR 45290: pointer initialization

[Janus Weil]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

Hi all,

the attached patch fixes one remaining problem with F08 (non-NULL)
pointer initialization: The F08 standard forbids using pointers as
initialization target in pointer initialization statements, which we
failed to detect up to now. Implementation is straightforward, once
you know how to read the standard in this matter. The patch was
regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus


2011-02-07  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/45290
	* expr.c (gfc_check_assign_symbol): Reject pointers as pointer
	initialization target.


2011-02-07  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/45290
	* gfortran.dg/pointer_init_6.f90: New.

[-- Attachment #2: pr45290.diff --]
[-- Type: application/octet-stream, Size: 1012 bytes --]

Index: gcc/fortran/expr.c
===================================================================
--- gcc/fortran/expr.c	(revision 169867)
+++ gcc/fortran/expr.c	(working copy)
@@ -3608,7 +3608,7 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_expr
 	             "must not be ALLOCATABLE ");
 	  return FAILURE;
 	}
-      if (!attr.target)
+      if (!attr.target || attr.pointer)
 	{
 	  gfc_error ("Pointer initialization target at %C "
 		     "must have the TARGET attribute");
@@ -3621,6 +3621,18 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_expr
 	  return FAILURE;
 	}
     }
+    
+  if (sym->attr.proc_pointer && rvalue->expr_type != EXPR_NULL)
+    {
+      /* F08:C1220. Additional checks for procedure pointer initialization.  */
+      symbol_attribute attr = gfc_expr_attr (rvalue);
+      if (attr.proc_pointer)
+	{
+	  gfc_error ("Procedure pointer initialization target at %L "
+		     "may not be a procedure pointer", &rvalue->where);
+	  return FAILURE;
+	}
+    }
 
   return SUCCESS;
 }

[-- Attachment #3: pointer_init_6.f90 --]
[-- Type: application/octet-stream, Size: 812 bytes --]

! { dg-do compile }
!
! PR 45290: [F08] pointer initialization

module m1
 implicit none
 type :: t
   integer, pointer :: p
   integer :: i
 end type
 integer, target :: i
 type(t), target :: x
 integer, pointer :: p1 => i
 integer, pointer :: p2 => p1   ! { dg-error "must have the TARGET attribute" }
 integer, pointer :: p3 => x%p  ! { dg-error "must have the TARGET attribute" }
 integer, pointer :: p4 => x%i
end module m1


module m2

 type :: t
   procedure(s), pointer, nopass :: ppc
 end type
 type(t) :: x
 procedure(s), pointer :: pp1 => s
 procedure(s), pointer :: pp2 => pp1    ! { dg-error "may not be a procedure pointer" }
 procedure(s), pointer :: pp3 => t%ppc  ! { dg-error "Syntax error" }

contains

  subroutine s
  end subroutine

end module m2

! { dg-final { cleanup-modules "m1 m2" } }

Re: [Patch, Fortran, F08] PR 45290: pointer initialization

[Tobias Burnus]

Janus Weil wrote:
> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?

OK and thanks for the patch.

Is part (2) of comment 5 actually fixed? ("Making global variables in a 
program SAVE_IMPLICIT.") Or rather: Is there a usage case where the user 
can see that this is not the case? I don't think there is ...

Tobias

PS: Unrelated to the current patch, but I do not like the error message 
for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290#c5 ("attempted 
assignment of UNKNOWN to INTEGER(4)").


> 2011-02-07  Janus Weil<janus@gcc.gnu.org>
>
> 	PR fortran/45290
> 	* expr.c (gfc_check_assign_symbol): Reject pointers as pointer
> 	initialization target.
>
>
> 2011-02-07  Janus Weil<janus@gcc.gnu.org>
>
> 	PR fortran/45290
> 	* gfortran.dg/pointer_init_6.f90: New.

Re: [Patch, Fortran, F08] PR 45290: pointer initialization

[Janus Weil]

>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> OK and thanks for the patch.

Thanks, Tobias. Committed as r169948.


> Is part (2) of comment 5 actually fixed? ("Making global variables in a
> program SAVE_IMPLICIT.") Or rather: Is there a usage case where the user can
> see that this is not the case? I don't think there is ...

I don't think it has been fixed, and I'm not sure if it actually would
make a difference. I'll note this as a possible to-do item in the PR.



> PS: Unrelated to the current patch, but I do not like the error message for
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290#c5 ("attempted assignment
> of UNKNOWN to INTEGER(4)").

Oops. I hadn't even noticed the typo in this test case. While the
error message is not *too* bad, it would be better to have the same
one as in:

 implicit none
 integer, target, save  :: t1
 integer, pointer :: p1
 p1 => t
end



 p1 => t
        1
Error: Symbol 't' at (1) has no IMPLICIT type


Another minor to-do item ...

Cheers,
Janus