From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10192 invoked by alias); 12 Apr 2011 02:54:52 -0000 Received: (qmail 10183 invoked by uid 22791); 12 Apr 2011 02:54:51 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 02:54:40 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3C2sbnA018441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Apr 2011 22:54:37 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p3C2sa7o024255; Mon, 11 Apr 2011 22:54:36 -0400 Received: from [10.3.113.84] (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p3C2sZn2023454; Mon, 11 Apr 2011 22:54:35 -0400 Message-ID: <4DA3BEEA.10608@redhat.com> Date: Tue, 12 Apr 2011 02:54:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Mike Stump CC: Laurynas Biveinis , Steven Bosscher , gcc-patches Patches Subject: Re: [gc-improv] Permanent vs function RTL obstack fix References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> <4DA35E74.1020506@redhat.com> <6E9E9711-46D0-4B15-BB5D-15253EE00753@comcast.net> In-Reply-To: <6E9E9711-46D0-4B15-BB5D-15253EE00753@comcast.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg00827.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/11/11 18:21, Mike Stump wrote: > On Apr 11, 2011, at 1:03 PM, Jeff Law wrote: >> The obvious solution is you copy the object, but then you have to be >> able to distinguish within the object, what fields point to other >> temporary objects vs permanent objects so that you can copy the >> referenced temporary objects, but not the permanent objects (other parts >> of the compiler may expect those permanent objects to be unique/shared). >> Not fun, not at all fun. Been there, done that. > > And then someone tells you that you can't copy... Usually a nasty bug report much later. So the choice is then, not solve a problem, or make everything permanent or add GC (back). :-) Been there, done that too. Right. Hence the old hack to mark the temporary obstacks and make them permanent (wasting an enormous amount of space in the process). I don't recall the name of that function, but it certainly made me barf. And yes, I remember all too well the problems with deep copying having written one of the earliest tree deep copy routines to support - -fcombine-statics . It was the source of more problems than I could ever count -- all related to objects allocated to different obstacks hanging off a single tree node or objects of two different types being stored into the same field within tree nodes. That was circa 1992/1993. These were the kind of problems that ultimately led to the GC system we have today. There are clearly things that can be better handled with different allocation models and I'll support moving to better models where it makes sense. Where it doesn't, obviously I won't support it. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNo77qAAoJEBRtltQi2kC7X0UH/0n1ydyhcvfjjoqhQCIwjf9J jp3MOel6I1RTjAMm69N0ZqCP5t8AuHIIJdlrSQ1Aworx0gNl4+VjbEXJEM6dcQB4 enJ5mYmPXQ3EMDEi6C/uPIGwPcPsqO9sFTe91plQIsI7m6OTRjM4I/aS9XmRQ/uQ 8qBhDTSY3sTn4rOTUvqKfvdStP9B/Sf2tYpYbHgm/tfLRQ5UFHWpZFckcyntHFs8 rTxcA3xKlVNSg2D9+3CfM8KVWqMVXeHgB+tlB2Q6L7/TAeCqGHABE5MxeB1+HDJN QoB0HCMCt7t6sqGYk6S5xayyfJUrWvt5XBiVa8oXrP9sVh1iNM8mY33zzwPE2M4= =9inU -----END PGP SIGNATURE-----