On Mon, 1 Jun 2015, Jan Beulich wrote: > >>> On 31.05.15 at 00:43, <andrew.coop...@citrix.com> wrote: > > On 30/05/2015 23:07, M A Young wrote: > >> On Fri, 29 May 2015, Andrew Cooper wrote: > >>> FC22 is miscompiling the C to: > >>> > >>> struct page_info *page = mfn_to_page(mfn); > >>> struct domain *owner = page_get_owner_and_reference(page); > >>> if ( owner ) > >>> put_page(mfn_to_page(0)); > >>> > >>> which is wrong, and why free_domheap_pages() does legitimately complain > >>> about the wonky refcount. > >> With a bit of experimentation I have found that compiling with the > >> -fno-caller-saves flag gets this code segment back to the Fedora 21 > >> version, thus avoiding the bug. > > > > After sending this email, I wondered whether the optimiser as assuming > > that %rdi was preserved. Indeed, it turns out that the generated code > > for page_get_owner_and_reference leaves %rdi unmodified, and safe for > > reuse after return. > > > > If the 'mov %r8,%rdi' were simply omitted, the code would work, as %rdi > > still contains the correct result of the original calculation. > > And %r8 is known to be preserved too? > > > Therefore, I suspect that the bug is in the -fcaller-saves optimisation > > code. > > I suppose together with us allowing it to do such for global functions > by marking everything hidden (i.e. something possibly not seeing much > testing). > > Questions now are: > 1) Was a bug against gcc opened already? > 2) What do we do about it? Working around the issue by setting > -fno-caller-saves seems awkward, as we'd likely have nothing but > the gcc version to tie this to. And considering distros carry their > own patch sets, the version alone may not even be enough. (I > didn't see any reports against our tip facing a similar issue despite > it being built with gcc 5 now too afaik.)
There is a Fedora bug on this https://bugzilla.redhat.com/show_bug.cgi?id=1219197 which I updated and reassigned to gcc yesterday. Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel