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.
