[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327
cvs-commit at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Apr 6 18:00:29 GMT 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989
--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:
https://gcc.gnu.org/g:e83714f65d1f75fc5af39f9fdc520a909dfc7635
commit r10-7570-ge83714f65d1f75fc5af39f9fdc520a909dfc7635
Author: Richard Sandiford <richard.sandiford@arm.com>
Date: Sat Apr 4 17:23:40 2020 +0100
lra: Stop eh_return data regs being incorrectly marked live [PR92989]
lra_assign has an assert to make sure that no pseudo is allocated
to a conflicting hard register. It used to be restricted to
!flag_ipa_ra, but in g:a1e6ee38e708ef2bdef4 I'd enabled it for
flag_ipa_ra too. It then tripped a few times while building
libstdc++ for mips-mti-linux.
Previous patches fixed one of the problems: registers clobbered
by the taking of an exception were being treated as live at the
beginning of the EH receiver, and this got propagated to predecessor
blocks. But it turns out that there was a second problem: eh_return
data registers were also being marked live in the same way.
These registers are defined by the unwinder and so in reality they
are live on entry to the EH receiver. But definitions can only happen
in blocks, not on edges, so for liveness purposes we use artificial
definitions at the start of the EH receiver. process_bb_lives should
therefore model the effect of a definition, not a plain use.
2020-04-06 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR rtl-optimization/92989
* lra-lives.c (process_bb_lives): Do not treat eh_return data
registers as being live at the beginning of the EH receiver.
More information about the Gcc-bugs
mailing list