On Sat, Feb 8, 2020 at 11:52 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Sat, Feb 08, 2020 at 11:32:40AM +0100, Uros Bizjak wrote: > > I think that the patch should also be backported to gcc-9 branch. The > > change is backward compatible, since the new code will save and > > restore zmm16+ registers at the caller site, and the old code (e.g. > > existing libraries) will then unnecessarily save and restore regs in > > the callee. > > Actually, it isn't backward compatible. > If both caller and callee touch xmm16+ (sure, unlikely), then if caller > is compiled by new gcc and callee by old gcc it is the case you described, > caller doesn't try to preserve values across the call and callee uselessly > saves them anyway (unless it fails to assemble due to SEH). > But if caller is compiled by old gcc and callee by new gcc, caller assumes > it can preserve values across the call in those registers and callee doesn't > save them and clobbers them.
I was considering only the most likely scenario where the compiler is upgraded without recompiling existing system libraries. So, with the new compiler installed, the new compiled code calls either new or old libraries. *Assuming* that old libraries never call new code, the situation is OK. As you point out, when the old code calls new code, registers get clobbered. By not backporting the patch, we can consider gcc-9 and gcc-10 ABI incompatible, otherwise the forward incompatibility moves in between gcc-9.2 and gcc-9.3. I agree that the former is somehow more convenient. IMO, this issue should be pointed out in the compiler release notes in any case. Uros.
