From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32585 invoked by alias); 12 Apr 2011 10:49:18 -0000 Received: (qmail 32572 invoked by uid 22791); 12 Apr 2011 10:49:17 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-gy0-f175.google.com (HELO mail-gy0-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 10:49:12 +0000 Received: by gyf1 with SMTP id 1so3685088gyf.20 for ; Tue, 12 Apr 2011 03:49:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.139.15 with SMTP id r15mr4154272ann.137.1302605351918; Tue, 12 Apr 2011 03:49:11 -0700 (PDT) Received: by 10.100.214.4 with HTTP; Tue, 12 Apr 2011 03:49:11 -0700 (PDT) In-Reply-To: References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> <4DA35E74.1020506@redhat.com> <6E9E9711-46D0-4B15-BB5D-15253EE00753@comcast.net> <4DA3BEEA.10608@redhat.com> <20110412070107.GB17079@tyan-ft48-01.lab.bos.redhat.com> Date: Tue, 12 Apr 2011 10:49:00 -0000 Message-ID: Subject: Re: [gc-improv] Permanent vs function RTL obstack fix From: Steven Bosscher To: Mike Stump Cc: Jakub Jelinek , Jeff Law , Laurynas Biveinis , gcc-patches Patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00852.txt.bz2 On Tue, Apr 12, 2011 at 12:44 PM, Mike Stump wrote: >> =A0 - If objects stored in PCH have pointers pointing outside of PCH-abl= e/GC-managed memory, these become wild pointers on PCH read even with GTY((= skip)) applied properly. However, not all GTY((skip)) pointers point outsid= e of PCH-able memory, so I have overloaded GTY((deletable)) option to reset= such fields to NULL on PCH write. This is only a part of the fix as logic = needs to be reviewed what to do with these NULLs after the PCH read. In cas= e of DECL_RTL, the NULL in the field causes re-creation of rtx anew, which = I think is the right thing. > > Not an example of a warm fuzzy. =A0When you combine this with the entire = idea of PCH, and that is to slosh to disk and back, the entire state of the= compiler, essentially, unmodified, we run into a conceptual gap. =A0Now, w= hy did PCH have that design, so that we could limit the number of pch bugs = and come up with a robust design that just works. =A0This is a useful prope= rty. I've debuged PCH bugs and they were usually a _result_ of the poor design. Missing GTY on non-pointer objects for example. There is nothing robust about the design of PCH and it certainly does not "just work". But, two things: 1. RTL and PCH should be completely separate. No DECL_RTL should ever end up in a PCH because DECL_RTL is not created in the front end (or should not be, it'd be a bug) 2. PCH as we know it will probably be gone soon (Google's pph stuff) Ciao! Steven