http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #6 from Allan Jensen <linux at carewolf dot com> --- (In reply to Richard Biener from comment #5) > Can you identify the inlined call? Is it > > if (pSLL && y == pSLL->scanline) { > loadAET(&AET, pSLL->edgelist); > pSLL = pSLL->next; > } > > or > > if (pSLL && y == pSLL->scanline) { > loadAET(&AET, pSLL->edgelist); > computeWAET(&AET); > pSLL = pSLL->next; > } > > ? > It is the first one (at least that is the one I have triggered). > Can you also show the correct and the invalid assembly snippet? I haven't really been able to identify it except that between code from loadAET and the following while loop, there appears to be no code loading the variable pAET which controls the loop, it appears to be loaded before loadAET, even though loadAET may change it. Note that I have made a work-around for the issue by making AET a pointer to an EdgeTableEntry on the heap instead of an object on the stack. I believe somehow the aliasing between AET and the pointers in loadAET which may point to it is lost by GCC. > > Not sure if it is possible, but having a "driver" around this (in > a separate compilation-unit) that calls PolygonRegion, verifying correct > output for correct input > and thus showing the miscompile would be nice (so there is a runtime > testcase). It doesn't matter if linking requires Qt. > > I am somewhat lost in that large function ;) I posted like this in case the description would be enough to make someone know where to look. If you need to debug it and dig into it, I will try to make a proper reduced test case.