This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Revamp fortran array types
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
>