This is the mail archive of the
mailing list for the GCC project.
[PING] [PATCH, FORTRAN] Fix PR fortran/60718
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Tobias Burnus <tobias dot burnus at physik dot fu-berlin 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: Wed, 30 Apr 2014 15:17:51 +0200
- Subject: [PING] [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>,<20140411140451 dot GA14778 at physik dot fu-berlin dot de>,<DUB129-W894C0A05B5A3C60B6251A6E4500 at phx dot gbl>
> Date: Tue, 15 Apr 2014 13:49:37 +0200
> Hi Tobias,
> On Fri, 11 Apr 2014 16:04:51, Tobias Burnus wrote:
>> Hi Tobias,
>> 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.
> Now I have created a test case for the different aliasing issues
> with may arise with scalar objects.
> As you pointed out, also conversions of allocatable -> nonalloc,
> allocatable -> pointer and nonalloc -> pointer turn out to
> violate the strict aliasing rules. However, conversions of
> arrays of objects with different attributes seem to be safe.
> I have not been able to find an example where it would be
> necessary to write the modified class object back to the original
> location. But I am not really a Fortran expert.
> Unfortunately there are also conversions of optional allocatable ->
> optional pointer, which complicate the whole thing quite a lot.
> I have found these in class_optional_2.f90.
> Boot-strapped and regression-tested on x86_64-linux-gnu.
> OK for trunk?