That's a GCC 4.6-4.8 regression. Pointer intents apply to the
association status and not to the value. Thus, assigning to an
intent(in) pointer is fine. The problem was that the LHS is no pointer
due to the array access ("dt%ptr(1) =") thus, the check got triggered.
Build and regtested on x86-64-linux.
OK for the trunk and the 4.6/4.7 branch?
Tobias
20012-04-12 Tobias Burnus <bur...@net-b.de>
PR fortran/52864
* expr.c (gfc_check_vardef_context): Fix assignment check for
pointer components.
20012-04-12 Tobias Burnus <bur...@net-b.de>
PR fortran/52864
* gfortran.dg/pointer_intent_6.f90: New.
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index e6a9c88..7ce693b 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4656,7 +4680,11 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer, bool alloc_obj,
if (ptr_component && ref->type == REF_COMPONENT)
check_intentin = false;
if (ref->type == REF_COMPONENT && ref->u.c.component->attr.pointer)
- ptr_component = true;
+ {
+ ptr_component = true;
+ if (!pointer)
+ check_intentin = false;
+ }
}
if (check_intentin && sym->attr.intent == INTENT_IN)
{
--- /dev/null 2012-04-12 06:55:49.927755790 +0200
+++ gcc/gcc/testsuite/gfortran.dg/pointer_intent_6.f90 2012-04-12 09:35:25.000000000 +0200
@@ -0,0 +1,19 @@
+! { dg-do compile }
+!
+! PR fortran/52864
+!
+! Assigning to an intent(in) pointer (which is valid).
+!
+ program test
+ type PoisFFT_Solver3D
+ complex, dimension(:,:,:), &
+ pointer :: work => null()
+ end type PoisFFT_Solver3D
+ contains
+ subroutine PoisFFT_Solver3D_FullPeriodic(D, p)
+ type(PoisFFT_Solver3D), intent(in) :: D
+ real, intent(in), pointer :: p(:)
+ D%work(i,j,k) = 0.0
+ p = 0.0
+ end subroutine
+ end
