Hello, Ping**2...
this is patch still pending: see https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00774.html for the latest version. Thanks, Bernd. > Date: Wed, 30 Apr 2014 15:17:51 +0200 > > 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. >> >
