Still aliasing problems left?

[Richard Guenther]

On Wed, 15 Sep 2004, Richard Guenther wrote:

> One can actually reproduce the problem using excessively large inlining
> parameters:
>
> -Dleafify=fooblah -O2 --param max-inline-insns-single=800
> --param large-function-insns=5000 --param inline-unit-growth=100000
>
> shows the failure, while adding -fno-strict-aliasing does not.  Testcase
> is (still) at
> http://www.tat.physik.uni-tuebingen.de/~rguenth/gcc/tramp3d-v3.cpp.gz
> segfault occours in MultiArgKernel<MultiArg, Function>::run() with
> Function=EvaluateLocLoop<Adv5::X::Massflow<3>, 3>.

Correction.  That's the failure place with leafification, with the above
inlining parameters it's MultiArgKernel<MultiArg, Function>::run() with
Function=EvaluateLocLoop<Adv5::X::MomentumfluxX<3>, 3> >.  The diff below
shows the case for leafify strict-aliasing vs. no-strict-aliasing.

The same failure is with -O1 vs -O1 -fstrict-aliasing, btw.

I'll file a summary bugreport tonight.

Richard.

>
> Direct diff of the offending functions optimized dump is noisy due to
> changing numbers, but omitting these shows two things:
>
> 1) Lots of trivial things like comparisons and additions are reversed,
>    like
>
> -  *&(&(ivtmp + pretmp)->D)->Ddomain_m = (&(ivtmp + pretmp)->D)->Ddomain_m;
> +  *&(&(pretmp + ivtmp)->D)->Ddomain_m = (&(pretmp + ivtmp)->D)->Ddomain_m;
>
>    and
>
> -  if (ivtmp != pretmp + 12B) goto <>; else goto <>;
> +  if (pretmp + 12B != ivtmp) goto <>; else goto <>;
>
> 2) It seems with -fno-strict-aliasing more "complex" expressions are
>    produced while with string-aliasing more temporaries are used like in
>
>    this = &this->data_m;
> -  D = (&this->blockControllerPtr_m)->ptr_m;
> -  D = (struct FieldEngineBaseData<3,double,BrickView> *) ((unsigned int) this->offset_m * 72);
> -  this = &(D->pBegin_m + D)->engine_m;
> +  this = &this->blockControllerPtr_m;
> +  this = &(this->ptr_m->pBegin_m + (struct FieldEngineBaseData<3,double,BrickView> *) ((unsigned int) this->offset_m * 72))->engine_m;
>
>    and
>
> -  offset = offset + (&ivtmp->D)->Ddomain_m * *ivtmp;
> +  offset = offset + (&ivtmp->D)->Ddomain_m * ivtmp->domain_mDDdomain_mbuffer[0];
>
>
> But apart from such stuff, I cannot see a difference that would lead to
> a segfault with strict-aliasing enabled.  So it maybe an RTL optimizer
> bug?
>
> Thanks in advance for any more suggestions on how to track this down,
>
> Richard.
>
>
>

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/