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:
>> Hmm,
>>
>> 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?


Thanks
Bernd.