This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PARCH 1/2, x86, PR63534] Fix darwin bootstrap
- From: Jeff Law <law at redhat dot com>
- To: Evgeny Stupachenko <evstupac at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Uros Bizjak <ubizjak at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, iains at gcc dot gnu dot org
- Date: Mon, 03 Nov 2014 15:40:58 -0700
- Subject: Re: [PARCH 1/2, x86, PR63534] Fix darwin bootstrap
- Authentication-results: sourceware.org; auth=none
- References: <CAOvf_xwDUU=gsQqHgybovAFHbn1+OVHYNBw+=xG0jau1wG2HDg at mail dot gmail dot com> <5453EDBD dot 9070303 at redhat dot com> <CAOvf_xyMLjcMcuLE8=+ygFFcRCtDCTMcOPKam=ORix=nPBPKmg at mail dot gmail dot com>
On 11/01/14 06:39, Evgeny Stupachenko wrote:
When PIC register is pseudo there is nothing special about it's value
that setjmp can hurt. So if the pseudo register lives across
setjmp_receiver RA should care about correct allocation (in case it is
not saved/restored, it should go on stack). gcc.dg tests and specs
I've tested behave like this.
If the allocator picked a call-clobbered register for the PIC register,
then we're obviously OK since the setjmp has to be expected to clobber
the PIC register.
But if the PIC register is in a call-saved register, then it's going to
be assumed to not be clobbered across calls and I don't believe that is
guaranteed for builtin setjmp/longjmp. Those restore SP, FP and an
ARGP, but not anything else by default.
So the callee might have clobbered the call saved hard register,
expecting to restore its value in its epilogue. But due to the longjmp,
that epilogue never gets called and thus the call-saved register won't
have the right value in the receiver.
Now if your argument is that IRA/LRA handle this, that's fine, a pointer
to that code would be appreciated so that it can be quickly audited.
Certainly the old local-alloc/global-alloc had magic for setjmp/longjmp
and maybe IRA/LRA does too, but it's better to be sure than just assume.
The initial problem comes from non-local goto as it tries to emit
pseudo PIC register after reload.
? You mean it emits a reference to the pseudo into RTL? That would
indicate that the allocators never put the pseudo into a hard
register?!? RTL dumps with a few pointers to key insns would help here.
jeff