https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #3 from Jan Hubicka <hubicka at ucw dot cz> --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 > > --- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> --- > Created attachment 49314 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49314&action=edit > Debug counter patch > > First bad debug counter value is -fdbg-cnt=ipa_mod_ref:2793. > Difference is for: TriaObjectAccessor<3, 3>::operator++(): > > LTO stores: > Limits: 32 bases, 16 refs > Base 0:struct TriaObjectAccessor (alias set 172) > Ref 0:int (alias set 6) > access: Parm 0 > access: Parm 0 param offset:0 offset:0 size:32 max_size:32 > > LTO stores: > Limits: 32 bases, 16 refs > Base 0:struct TriaObjectAccessor (alias set 172) > Ref 0:int (alias set 6) > access: Parm 0 param offset:0 offset:32 size:32 max_size:32 > access: Parm 0 param offset:0 offset:0 size:32 max_size:32 Thanks a lot for trakcing it down. At the first glance, the summary looks correct. I hope this is just another manifestation of the bug about mem_ref offsets, but I will take a lok. Pehraps it would be more useful to add debug counter to the place disambiguation is done (where we dump ipa-modref: in tree-ssa-alias. That way we would have both the summary and the access. Honza > > template <int dim> > inline > void > TriaObjectAccessor<3,dim>::operator ++ () > { > ++this->present_index; > // is index still in the range of > // the vector? > while (this->present_index > >= > > static_cast<int>(this->tria->levels[this->present_level]->hexes.hexes.size())) > { > // no -> go one level up > ++this->present_level; > this->present_index = 0; > // highest level reached? > if (this->present_level >= static_cast<int>(this->tria->levels.size())) > { > // return with past the end pointer > this->present_level = this->present_index = -1; > return; > }; > }; > } > > hope it helps. > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug.
