This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ICE in change_address at emit_rtl.c
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: Neil Booth <neil at daikokuya dot demon dot co dot uk>, Gabriel Dos Reis <gdr at codesourcery dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 26 Nov 2001 11:50:10 -0800
- Subject: Re: ICE in change_address at emit_rtl.c
--On Monday, November 26, 2001 11:45:51 AM -0800 Zack Weinberg
<zack@codesourcery.com> wrote:
> On Sun, Nov 25, 2001 at 12:38:33AM -0800, Mark Mitchell wrote:
>> > (Oh, can we please #if 0 out the aux field in tree_common? The only
>> > code that's using it is on the ast-optimizer-branch which will not be
>> > merged in 3.1 - all it's doing is wasting memory.)
>>
>> Just remove it, until the branch is merged. And then we might want
>> to use an on-the-side table, depending.
>>
>> Patch pre-approved.
>
> Neil tried to do this a few weeks back and got shot down because
> apparently it would make trunk->branch merges harder. What has
> changed?
That I didn't see the original discussion, and therefore waded in
with a new, unilateral decision, thinking that nobody had made a
decision before.
But, I justify my decision like this:
1. The trunk should be focused on the 3.1 release, and this field
has no value in that release.
2. It is unclear that this is even the right data structure to use.
Inflating the size of all trees, just for use during the AST
optimization phase, is not necessarily a good design.
3. How much harder is the merge? The next time you merge to the
branch, you manually keep the aux field. Then you have it
forever more.
Certainly, in general, people working on branches have to be willing
to tolerate shakeups on the mainline. Recall that I have a new C++
parser branch sitting in limbo like this, so I feel the pain along
with everyone else.
Since there is apparently conflict, we should give the people who
originally opposed removing aux a chance to debate.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com