RFA: Revamp fortran array types

Richard Guenther richard.guenther@gmail.com
Tue Aug 18 16:07:00 GMT 2009


On Tue, Aug 18, 2009 at 5:14 PM, Steve
Kargl<sgk@troutmask.apl.washington.edu> wrote:
> On Tue, Aug 18, 2009 at 04:40:17PM +0200, Michael Matz wrote:
>> Hmm, richi tried polyhedron and verified that it is the
>> tree-ssa-structalias.c hunk.  Unfortunately that hunk alone is already a
>> correctness fix, as demonstrated with this testcase:
>>
>> ----------------------------------
>>   integer, target :: foo
>>   integer, pointer :: p,p2
>>   integer :: i
>>   p=>foo
>>   p2=>foo
>>   i = clobber(p,p2)
>>   if (i /= 2) call abort
>> contains
>>   function clobber(p,p2)
>>     integer clobber
>>     integer, pointer :: p,p2
>>     p = 1
>>     p2 = 2
>>     clobber = p
>>   end function
>> end
>> ----------------------------------
>>
>> An unpatched compiler with "-O2 -fno-inline" will make this testcase
>> abort, exactly due to the hack called flag_argument_noalias.
>
> Michael,
>
> The above code is technically invalid Fortran, so a compiler
> can do whatever it wants.  The abort is a possible "correct"
> result.  The standard prohits a programmer from aliasing
> the input arguments.  The standard also does not require a
> compiler to detect aliasing.

Doesn't that effectively make pointer and targets useless?  Or
is the scope where a compiler is not required to detect
aliasing somehow restricted?

Thus for

  p => a
  p2 => a
  p = 1
  p2 = 2

the compiler is allowed to re-oder the two stores?

Richard.

> With that said, I regression tested your patch on amd64-*-freebsd.
> There were no regressions.  Tobias has already approved your
> patch, and I see no reason to not commit it (based on Tobias's
> Polyhedron benchmark results).
> --
> Steve
>



More information about the Gcc-patches mailing list