Ping...
> 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: >>> 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. >