[Bug fortran/53939] New: allows assignment to INTENT(IN) nested component

[Bug fortran/53939] New: allows assignment to INTENT(IN) nested component

[Bil.Kleb at NASA dot gov]

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

             Bug #: 53939
           Summary: allows assignment to INTENT(IN) nested component
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Bil.Kleb@NASA.gov


I cannot get gfortran to complain when I assign something to an INTENT(IN)
variable, viz,

$ gfortran --version | head -1
GNU Fortran (GCC) 4.6.2 20111019 (prerelease)

$ cat > intent.f90 << EOF
module types
  type elem_type
    integer                        :: ncell
    integer, dimension(:), pointer :: cl2g
  end type
  type grid_type
    integer                                :: nelem
    type(elem_type), dimension(:), pointer :: elem 
  end type
end module

module nested_intents
  use types, only: grid_type
 contains
  subroutine pass_through( grid )
    type(grid_type), intent(in) :: grid
    call intent_inout( grid )
  end subroutine
  subroutine intent_inout( grid )
    type(grid_type), intent(in) :: grid ! should produce error: grid changed
    integer :: i, j
    do i = 1,grid%nelem
      do j = 1, grid%elem(i)%ncell
        grid%elem(i)%cl2g(j) = grid%elem(i)%cl2g(j) + 1
      end do
    end do
  end subroutine
end module
EOF

% gfortran -c -W -Wall -Wextra -pedantic-errors intent.f90 
%

The old DEC compiler complains,

alpha% % fort -what
    Compaq Fortran V1.2.0-1882
    Compaq Fortran Compiler V1.2.0-1882-48BBF

alpha% fort -c intent.f90 
f90: Error: intent.f90, line 24: There is an assignment to a dummy symbol with
the explicit INTENT(IN) attribute   [GRID]
        grid%elem(i)%cl2g(j) = grid%elem(i)%cl2g(j) + 1
--------^

[Bug fortran/53939] allows assignment to INTENT(IN) nested component

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |burnus at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-07-12 13:23:53 UTC ---
Congratulation, you found another bug in the Compaq compiler.

[Sorry for the slight sarcasm. gfortran like any piece of software has bugs and
we are happy if users report them. I also won't rule out that the my first
analysis is wrong, but your example seems to be a pretty clear cut case.]


You change:
  grid%elem(i)%cl2g(j) = grid%elem(i)%cl2g(j) + 1

where
  type(grid_type), intent(in) :: grid

However, both "elem" and "cl2g" are pointers - thus the "intent(in)" doesn't
apply. [Or more precisely, for "cl2g" the intent doesn't apply at all (as it is
underneath a pointer component) while for "elem" it only applies to
pointer-association changes: Namely, pointer assignment and
allocate/deallocate/nullify of "cl2g" is prohibited due to intent(in), changing
its value is allowed.]


I think in the normative text of the Fortran standard it is a bit hidden, hence
I quote the following nonnormative note from the Fortran 2008 standard:


"NOTE 5.16
If a dummy argument is a derived-type object with a pointer component, then the
pointer as a pointer is a subobject of the dummy argument, but the target of
the pointer is not. Therefore, the restrictions on subobjects of the dummy
argument apply to the pointer in contexts where it is used as a pointer, but
not in contexts where it is dereferenced to indicate its target. For example,
if X is a dummy argument of derived type with an integer pointer component P,
and X is INTENT (IN), then the statement
  X%P => NEW_TARGET
is prohibited, but
  X%P = 0
is allowed (provided that X%P is associated with a definable target)."

[Bug fortran/53939] allows assignment to INTENT(IN) nested component

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-07-12 13:29:08 UTC ---
(In reply to comment #1)
> However, both "elem" and "cl2g" are pointers - thus the "intent(in)" doesn't
> apply. [Or more precisely, for "cl2g" the intent doesn't apply at all (as it
> is underneath a pointer component) while for "elem" it only applies to
> pointer-association changes: Namely, pointer assignment and
> allocate/deallocate/nullify of "cl2g" is prohibited due to intent(in),

  That "cl2g" should have been "elem" - sorry for the typo.

> changing its value is allowed.]

[Bug fortran/53939] allows assignment to INTENT(IN) nested component

[Bil.Kleb at NASA dot gov]

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

--- Comment #3 from Bil Kleb <Bil.Kleb at NASA dot gov> 2012-07-12 13:32:07 UTC ---
OK, fair enough (and sincere thanks for taking the time to explain it).

I see that if I change to the more modern ALLOCATABLE declarations, then I get
a warning about assigning to an INTENT(IN).

Thanks again, and sorry for the trouble.