From: Mark Mitchell <mark@codesourcery.com>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Neil Booth <neil@daikokuya.demon.co.uk>,
Gabriel Dos Reis <gdr@codesourcery.com>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: ICE in change_address at emit_rtl.c
Date: Sat, 17 Nov 2001 09:56:00 -0000 [thread overview]
Message-ID: <105050000.1006804210@gandalf.codesourcery.com> (raw)
In-Reply-To: <20011126114551.C19531@codesourcery.com>
--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
WARNING: multiple messages have this Message-ID
From: Mark Mitchell <mark@codesourcery.com>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Neil Booth <neil@daikokuya.demon.co.uk>,
Gabriel Dos Reis <gdr@codesourcery.com>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: ICE in change_address at emit_rtl.c
Date: Mon, 26 Nov 2001 11:55:00 -0000 [thread overview]
Message-ID: <105050000.1006804210@gandalf.codesourcery.com> (raw)
Message-ID: <20011126115500.Mtn7IYKR3T5PdaRi-CRjTGjTpG2WfK_ItJhUTT_dv0k@z> (raw)
In-Reply-To: <20011126114551.C19531@codesourcery.com>
--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
next prev parent reply other threads:[~2001-11-26 19:55 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-13 6:18 Craig Rodrigues
2001-11-13 8:25 ` Gerald Pfeifer
2001-11-13 8:39 ` Craig Rodrigues
2001-11-13 8:40 ` Gerald Pfeifer
2001-11-13 14:52 ` Gerald Pfeifer
2001-11-13 16:41 ` Zack Weinberg
2001-11-13 16:55 ` Neil Booth
2001-11-13 18:07 ` Gabriel Dos Reis
2001-11-13 18:09 ` Neil Booth
2001-11-14 9:46 ` Zack Weinberg
2001-11-14 10:02 ` Neil Booth
2001-11-14 10:06 ` Joseph S. Myers
2001-11-14 10:10 ` Neil Booth
2001-11-14 10:19 ` Joseph S. Myers
2001-11-14 14:16 ` Gabriel Dos Reis
2001-11-14 17:34 ` Michal Moskal
2001-11-14 13:55 ` Gabriel Dos Reis
2001-11-14 15:00 ` Neil Booth
2001-11-14 16:50 ` Gabriel Dos Reis
2001-11-14 12:43 ` Phil Edwards
2001-11-15 0:55 ` Mark Mitchell
2001-11-15 1:22 ` Gabriel Dos Reis
2001-11-15 1:44 ` Neil Booth
2001-11-15 4:55 ` Zack Weinberg
2001-11-15 5:19 ` Joseph S. Myers
2001-11-15 6:58 ` Zack Weinberg
2001-11-15 9:07 ` Mark Mitchell
2001-11-17 9:40 ` Zack Weinberg
2001-11-17 9:56 ` Mark Mitchell [this message]
2001-11-18 4:44 ` Zack Weinberg
2001-11-26 16:45 ` Zack Weinberg
2001-11-26 11:55 ` Mark Mitchell
2001-11-26 11:46 ` Zack Weinberg
2001-11-25 0:42 ` Mark Mitchell
2001-11-15 9:23 ` Neil Booth
2001-11-17 10:37 ` Zack Weinberg
2001-11-17 10:54 ` Neil Booth
2001-11-26 12:25 ` Neil Booth
2001-11-26 12:07 ` Zack Weinberg
2001-11-25 3:50 ` Neil Booth
2001-11-15 5:14 ` Mark Mitchell
2001-11-16 6:27 ` Fergus Henderson
2001-11-16 8:32 ` Daniel Berlin
2001-11-25 22:49 ` Daniel Berlin
2001-11-25 22:06 ` Fergus Henderson
2001-11-15 3:02 ` Zack Weinberg
2001-11-16 4:04 ` Fergus Henderson
2001-11-25 21:58 ` Fergus Henderson
2001-11-13 16:47 dewar
2001-11-14 12:01 mike stump
2001-11-14 14:57 ` Neil Booth
2001-11-14 16:35 ` Gabriel Dos Reis
2001-11-15 9:00 ` Mark Mitchell
2001-11-25 0:41 ` Mark Mitchell
2001-11-15 8:02 mike stump
2001-11-15 9:51 ` Neil Booth
2001-11-25 4:02 ` Neil Booth
2001-11-15 8:15 mike stump
2001-11-15 8:43 ` Zack Weinberg
2001-11-24 23:06 ` Zack Weinberg
2001-11-15 10:14 Richard Kenner
2001-11-15 10:36 ` Neil Booth
2001-11-25 5:06 ` Neil Booth
2001-11-25 4:23 ` Richard Kenner
2001-11-15 11:05 Richard Kenner
2001-11-15 12:07 ` Neil Booth
2001-11-25 5:23 ` Neil Booth
2001-11-15 14:55 ` Per Bothner
2001-11-25 10:27 ` Per Bothner
2001-11-25 5:13 ` Richard Kenner
2001-11-15 12:28 Richard Kenner
2001-11-15 12:44 ` Neil Booth
2001-11-25 5:33 ` Neil Booth
2001-11-25 5:25 ` Richard Kenner
2001-11-15 13:20 Richard Kenner
2001-11-15 13:20 ` Neil Booth
2001-11-25 6:34 ` Neil Booth
2001-11-16 8:52 ` Richard Henderson
2001-11-25 23:22 ` Richard Henderson
2001-11-25 6:29 ` Richard Kenner
2001-11-15 14:19 Richard Kenner
2001-11-25 6:42 ` Richard Kenner
2001-11-15 16:24 Richard Kenner
2001-11-15 17:08 ` Per Bothner
2001-11-25 14:33 ` Per Bothner
2001-11-25 13:44 ` Richard Kenner
2001-11-15 17:25 Richard Kenner
2001-11-15 17:39 ` Per Bothner
2001-11-25 14:50 ` Per Bothner
2001-11-25 14:37 ` Richard Kenner
2001-11-15 17:44 Richard Kenner
2001-11-15 19:52 ` Per Bothner
2001-11-25 16:13 ` Per Bothner
2001-11-25 15:01 ` Richard Kenner
2001-11-15 20:12 Richard Kenner
2001-11-15 20:19 ` Per Bothner
2001-11-25 16:48 ` Per Bothner
2001-11-25 16:24 ` Richard Kenner
2001-11-15 23:55 Richard Kenner
2001-11-25 17:22 ` Richard Kenner
2001-11-16 9:26 Richard Kenner
2001-11-26 3:15 ` Richard Kenner
2001-11-17 11:19 mike stump
2001-11-26 12:54 ` mike stump
2001-11-17 11:23 mike stump
2001-11-26 13:29 ` mike stump
2001-11-17 11:46 Richard Kenner
2001-11-26 13:36 ` Richard Kenner
2001-11-17 17:09 mike stump
2001-11-17 20:34 ` Per Bothner
2001-11-26 14:58 ` Per Bothner
2001-11-26 14:51 ` mike stump
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=105050000.1006804210@gandalf.codesourcery.com \
--to=mark@codesourcery.com \
--cc=gcc@gcc.gnu.org \
--cc=gdr@codesourcery.com \
--cc=neil@daikokuya.demon.co.uk \
--cc=zack@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).