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