This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/13653] [3.3 regression] -O2 -funroll-loop miscompiles POOMA testcase
- From: "rguenth at tat dot physik dot uni-tuebingen dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Jan 2004 22:45:39 -0000
- Subject: [Bug optimization/13653] [3.3 regression] -O2 -funroll-loop miscompiles POOMA testcase
- References: <20040112101346.13653.rguenth@tat.physik.uni-tuebingen.de>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-01-29 22:45 -------
Subject: Re: [3.3 regression] -O2 -funroll-loop
miscompiles POOMA testcase
On Thu, 29 Jan 2004, Richard Guenther wrote:
> On Thu, 29 Jan 2004, dberlin at gcc dot gnu dot org wrote:
>
> > I'll attach my even *more* reduced testcase, but that only passes at -O2 and
> > fails at -O2 -funroll-loops (IE it doesn't pass at -O0 or -O1)
>
> That does hint to maybe a stack corruption or somehow. That would be
> consistent with my observation that the original testcase fails only, if I
> enable assertions in the code, if I disable them and they get #ifdef'ed
> away, the failure does not occour.
>
> So it may be interesting to look at the generated assembly of the main
> function and looking for corrupt stack after calls?
Additionally to the noreturn attribute, I can reduce the main function to
int main(int argc, char *argv[]) {
Interval<1> D(6);
Interval<3> I3(D,D,D);
Loc<3> blocks(2,2,2);
UniformGridPartition<3> partition(blocks);
UniformGridLayout<3> layout(I3, partition,ReplicatedTag());
Array<3, double, MultiPatch<UniformTag,Brick> > u(layout);
for (int i2 = 0; i2 < 4 /* 3 doesnt segfault */; i2++)
for (int i1 = 0; i1 < 1; i1++)
for (int i0 = 0; i0 < 1; i0++)
u(i0,i1,i2) = 0;
return 0;
}
and still get the segfault, but it is fixed with either running the first
loop only to i2 < 3, or removing any of the loops.
In fact, looking at the assembler, there are two calls to
_ZNK21UniformGridLayoutDataILi3EE8globalIDEiii inside the loop, and the
loop itself doesnt change with the noreturn attribute on toss_cookies, but
the called function does, as it calls toss_cookies several times.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13653