This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]