Still aliasing problems left?

[Richard Guenther]

On Wed, 15 Sep 2004, Richard Guenther wrote:

> I still get segfaults with -O2 and succeeds for -O2 -fno-strict-aliasing
> with the tramp3d-v3 testcase with leafify included.
>
> I'm not going to submit a bugreport, because reproducing without leafify
> is not possible.  But I'll try to compare optimized tree dumps (or hint
> me at more useful ones).

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>.

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.