This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, FORTRAN] Fix PR fortran/60718
- From: Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>
- Date: Fri, 11 Apr 2014 16:04:51 +0200
- Subject: Re: [PATCH, FORTRAN] Fix PR fortran/60718
- Authentication-results: sourceware.org; auth=none
- References: <20140411113733 dot GA7852 at physik dot fu-berlin dot de> <DUB129-W758F350DCBDF46944FC3A5E4540 at phx dot gbl>
On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote:
> On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote:
> I was hoping somehow that only that test case is broken,
> and needs to be fixed. The target attribute is somehow simple,
> it implies intent(in) and the actual value will in most cases
> be a pointer, as in the example.
I think that passing another nonpointer TARGET to a dummy argument
which has a TARGET attribute is at least as common as passing a
POINTER to a TARGET.
TARGET is roughtly the opposite to the restrict qualifier. By default
any nonpointer variable does not alias with something else, unless
it has the TARGET attribute; if it has, it (its address) can then
be assigned to a pointer. POINTER intrinsically alias and cannot
have the TARGET attribute.
> > Pointer -> Nonalloc
> > Allocatable -> Noalloc
> > Nonallocatable*/Allocatable* -> Pointer with intent(in)
> Well, this approach does not handle intent(inout) at all.
Note: Intent(in) can mean two different things. For normal variables,
it means that those may not be modified at all (although, the value
but not address of pointer components of structs [derived types]
is permitted to be changed). And for pointers, it means that the
pointer association status may not be changed (i.e. the pointer
address, allocating, deallocating) - the value of the variable to
which the pointer points to may still be modified.
> If that is possible, the changed value must be written back again.
> Are there any test cases for these conversions?
For normal variables: Sure. For polymorphic variables, I have no idea.
I am also not sure whether the value has to be written back or not; if
only the value of the address pointed to changes and not the pointer
itself (which can't in this context), everything should be fine.
In any case, I am not really happy with the way we handle polymorphic
types - and I am considering to change it when we implement the new
Another issue is the handling of the restrict qualifier. GCC's
implementation is not really compatible with the Fortran standard and
gfortran's use. To fix that properly, we need Michael Matz restrict
> > Thus, you need to handle those; gfc_expr_attr(e) should give you
> > information about the expression. Or one could always check against
> > gfc_typenode_for_spec (&fsym->ts);
> > of both fsym and e.
> I am not sure, does gfc_typenode_for_spec always allocate new nodes?
No idea - I had to look at the source code.