This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Jan 2010 17:17:49 -0000
- Subject: [Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails
- References: <bug-42896-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #10 from rguenther at suse dot de 2010-01-29 17:17 -------
Subject: Re: [4.5 Regression] Random debug generation
differences, bootstrap fails
On Fri, 29 Jan 2010, jakub at gcc dot gnu dot org wrote:
> ------- Comment #9 from jakub at gcc dot gnu dot org 2010-01-29 16:43 -------
> In theory we could reuse the next_containing_mem field for a counter, as it
> isn't used for anything once cselib_preserve_only_values is called (and I
> believe canon_value_cmp is only ever used after vt_initialize phase finishes,
> i.e. all VALUEs have gone through cselib_preserve_only_values.
> remove_useless_values could have a bool argument which
> cselib_preserve_only_values would set, then it would just set an int in union
> with next_containing_mem to a counter (incremented after each
> cselib_preserve_only_values call starting at cselib_init).
> The trouble is how to teach GC not to walk next_containing_mem / this int (it
> isn't needed to walk next_containing_mem anyway, as all the VALUEs must be in
> the hash table anyway).
Or we could simply record the basic-block and use its index for
tie-breaking?
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42896