public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/53939] New: allows assignment to INTENT(IN) nested component
@ 2012-07-12 12:28 Bil.Kleb at NASA dot gov
2012-07-12 13:24 ` [Bug fortran/53939] " burnus at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Bil.Kleb at NASA dot gov @ 2012-07-12 12:28 UTC (permalink / raw)
To: gcc-bugs
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
--------^
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/53939] allows assignment to INTENT(IN) nested component
2012-07-12 12:28 [Bug fortran/53939] New: allows assignment to INTENT(IN) nested component Bil.Kleb at NASA dot gov
@ 2012-07-12 13:24 ` burnus at gcc dot gnu.org
2012-07-12 13:29 ` burnus at gcc dot gnu.org
2012-07-12 13:32 ` Bil.Kleb at NASA dot gov
2 siblings, 0 replies; 4+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-07-12 13:24 UTC (permalink / raw)
To: gcc-bugs
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)."
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/53939] allows assignment to INTENT(IN) nested component
2012-07-12 12:28 [Bug fortran/53939] New: allows assignment to INTENT(IN) nested component Bil.Kleb at NASA dot gov
2012-07-12 13:24 ` [Bug fortran/53939] " burnus at gcc dot gnu.org
@ 2012-07-12 13:29 ` burnus at gcc dot gnu.org
2012-07-12 13:32 ` Bil.Kleb at NASA dot gov
2 siblings, 0 replies; 4+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-07-12 13:29 UTC (permalink / raw)
To: gcc-bugs
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.]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/53939] allows assignment to INTENT(IN) nested component
2012-07-12 12:28 [Bug fortran/53939] New: allows assignment to INTENT(IN) nested component Bil.Kleb at NASA dot gov
2012-07-12 13:24 ` [Bug fortran/53939] " burnus at gcc dot gnu.org
2012-07-12 13:29 ` burnus at gcc dot gnu.org
@ 2012-07-12 13:32 ` Bil.Kleb at NASA dot gov
2 siblings, 0 replies; 4+ messages in thread
From: Bil.Kleb at NASA dot gov @ 2012-07-12 13:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-07-12 13:32 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-12 12:28 [Bug fortran/53939] New: allows assignment to INTENT(IN) nested component Bil.Kleb at NASA dot gov
2012-07-12 13:24 ` [Bug fortran/53939] " burnus at gcc dot gnu.org
2012-07-12 13:29 ` burnus at gcc dot gnu.org
2012-07-12 13:32 ` Bil.Kleb at NASA dot gov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).