This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR rtl-optimization/55604]: fix ICE in remove_some_program_points_and_update_live_ranges
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: "Vladimir N. Makarov" <vmakarov at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 5 Dec 2012 19:26:00 +0100
- Subject: Re: [PR rtl-optimization/55604]: fix ICE in remove_some_program_points_and_update_live_ranges
- References: <50BF8ECF.4010804@redhat.com>
On Wed, Dec 5, 2012 at 7:13 PM, Aldy Hernandez wrote:
> This is a division by zero ICE.
>
> In the testcase in the PR, both `n' and `lra_live_max_point' are zero. I
> have opted to inhibit the dump when lra_live_max_point is zero, but I can
> just as easily avoiding printing the percentage in this case.
Test case?
Also, it'd be preferable if you can also update
remove_some_program_points_and_update_live_ranges in ira-lives.c -- it
seems to me that at some point we're going to want to merge the almost
identical functions from LRA and IRA but that gets harder if they
start diverging.
> Let me know what you prefer.
How can you end up with lra_live_max_point==0? AFAIU that can only
happen if you have no live ranges at all (no program points) or if
somehow the curr_point counter got messed up. The former case would
mean you shouldn't end up calling
remove_some_program_points_and_update_live_ranges to begin with (no
program points being there to remove), the latter case would be a bug.
I don't think this is the correct fix.
Ciao!
Steven