From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29154 invoked by alias); 12 Apr 2011 10:44:08 -0000 Received: (qmail 29143 invoked by uid 22791); 12 Apr 2011 10:44:08 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta05.emeryville.ca.mail.comcast.net (HELO qmta05.emeryville.ca.mail.comcast.net) (76.96.30.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 10:44:02 +0000 Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta05.emeryville.ca.mail.comcast.net with comcast id Wajk1g0020b6N64A5ak2Ey; Tue, 12 Apr 2011 10:44:02 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta03.emeryville.ca.mail.comcast.net with comcast id Wak11g00A0BKwT48Pak1HL; Tue, 12 Apr 2011 10:44:02 +0000 Subject: Re: [gc-improv] Permanent vs function RTL obstack fix Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mike Stump In-Reply-To: Date: Tue, 12 Apr 2011 10:44:00 -0000 Cc: Jakub Jelinek , Jeff Law , Laurynas Biveinis , gcc-patches Patches Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Steven Bosscher 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/msg00849.txt.bz2 On Apr 12, 2011, at 1:45 AM, Steven Bosscher wrote: > On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek wrote: >> On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote: >>> I think all these comments from you "old guys" ;-) are more >>> discouraging than fair. What Laurynas and Bernd have done, is nothing >>=20 >> It is IMHO completely fair to point that the risks this brings in >> a huge maintainance nightmare are very high. >=20 > And IM-equally-HO it is completely unfair to talk about risks in any > situation where there is nothing yet to talk about! Give it a chance > and wait for something that's more than just an idea, and then assess > the risks based on an implementation. The problem is that in the olden days, people thought it would work, then, = they ran into, oh, but the lifetime is wrong. Oh, but I don't know what th= e lifetime will be before I start allocating. Oh, what do you mean I can't= copy it... All these things happened after real bug reports and great dif= ficulty in tracking down real problems. A review might not be able to spot= the things that won't work. We don't want to discourage, only to let ever= yone know what our experience is with these sorts of problems. So, for exa= mple, if one is predicating copying objects to solve lifetime problems, we = can expound what some of the problems were in the past. They could be rele= vant, they might not be not relevant; also, they just might cause people to= explore an area that might be a problem, find and address it sooner. Also, actual patches have been posted since Jan 27th... I don't see that a= ll the problems are cleverly avoided. So, let's take one: > - If objects stored in PCH have pointers pointing outside of PCH-able/G= C-managed memory, these become wild pointers on PCH read even with GTY((ski= p)) applied properly. However, not all GTY((skip)) pointers point outside o= f PCH-able memory, so I have overloaded GTY((deletable)) option to reset su= ch fields to NULL on PCH write. This is only a part of the fix as logic nee= ds to be reviewed what to do with these NULLs after the PCH read. In case o= f DECL_RTL, the NULL in the field causes re-creation of rtx anew, which I t= hink is the right thing. Not an example of a warm fuzzy. When you combine this with the entire idea= of PCH, and that is to slosh to disk and back, the entire state of the com= piler, essentially, unmodified, we run into a conceptual gap. Now, why did= PCH have that design, so that we could limit the number of pch bugs and co= me up with a robust design that just works. This is a useful property. Now, one can audit DECL_RTL, to see if it matters, but there are roughly 34= 4 places to check. I glanced at a few, to see if I can spot problems. I f= ind it hard to know if any particular one will be a problem. At least some= of them can't be found by testing. Presently we do what I'd call smoke te= sting for pch. Deeper issues aren't covered. So, who then will spot the i= ssues?