Comments
Patch
20012-04-12 Tobias Burnus <burnus@net-b.de>
PR fortran/52864
* expr.c (gfc_check_vardef_context): Fix assignment check for
pointer components.
20012-04-12 Tobias Burnus <burnus@net-b.de>
PR fortran/52864
* gfortran.dg/pointer_intent_6.f90: New.
@@ -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)
{
@@ -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
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