http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #18 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-26
13:23:59 UTC ---
(In reply to comment #13)
> Ugh. That might be terrible. Can you point to some language in the standard
> supporting that (I haven't looked myself and am not too fluent in the fortran
> standard).
(All relative to Fortran 2008,
ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf)
"5.3.17 TARGET attribute"
[...]
"If an object has the TARGET attribute, then all of its nonpointer subobjects
also have the TARGET attribute."
The pointer part probably enters indirectly: Assume in "a%b%p%d", "p" is the
pointer than "a%b%p%d" denotes the "d" components of the target to which
"a%b%p" points to. Per construction the target of the pointer has the TARGET
attribute - and "d" has it via the rule above.
Note, however, that the TARGET issue is local. Example:
type t
integer :: i
end type t
type(t) :: a
integer, pointer :: ptr
call sub(a)
ptr = 7 ! Invalid, ptr has unknown association
! status as "a" is not a TARGET
contains
subroutine sub(x)
type(a), TARGET :: x
ptr => x%i ! OK, x and thus x%i is a TARGET
ptr = 5
end subroutine
end
Reason: "If the dummy argument has the TARGET attribute and the effective
argument does not have the TARGET attribute [...], any pointers associated with
the dummy argument become undefined when execution of the procedure completes."
(Cf. "12.5.2.4 Ordinary dummy variables".)
See also: "16.5.2.5 Events that cause the association status of pointers to
become undefined".
(In reply to comment #15)
> You then need to make sure to create variant types of aggregates with the
> target attribute applied to all subtypes (thus, the restrict stuff removed)
> as the middle-end doesn't know about this rule.
Yes, that sounds sensible - even though it will be a lot of work and requires
quite some book keeping :-(
That's somehow the curse of -fwhole-file: Now the decls are sensible enough
that the ME has plenty of opportunities to exploit all the wrong decl the FE
generates...
(In reply to comment #16)
> I think this implies this bug depends in somehow on PR45777.
Maybe. One operates on gfc_expr level - the other on tree level; however, both
are about the same issue. I assume they independent of each other.
