public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).