From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4619 invoked by alias); 11 Dec 2003 20:21:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4611 invoked from network); 11 Dec 2003 20:21:05 -0000 Received: from unknown (HELO desire.geoffk.org) (24.6.229.131) by sources.redhat.com with SMTP; 11 Dec 2003 20:21:05 -0000 Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id hBBKJck31286; Thu, 11 Dec 2003 12:19:38 -0800 Date: Thu, 11 Dec 2003 21:15:00 -0000 From: Geoff Keating Message-Id: <200312112019.hBBKJck31286@desire.geoffk.org> To: amacleod@redhat.com CC: gcc@gcc.gnu.org In-reply-to: <1071162566.10380.254.camel@p4> (message from Andrew MacLeod on 11 Dec 2003 12:09:24 -0500) Subject: Re: [tree-ssa][ GC, Virtual operands, and GCing between passes References: <1070998524.17667.2860.camel@p4> <1071016677.17667.2918.camel@p4> <1071162566.10380.254.camel@p4> X-SW-Source: 2003-12/txt/msg00675.txt.bz2 > X-Original-To: geoffk@foam.wonderslug.com > From: Andrew MacLeod > Cc: gcc mailing list > Date: 11 Dec 2003 12:09:24 -0500 > X-OriginalArrivalTime: 11 Dec 2003 17:01:50.0062 (UTC) FILETIME=[77EA48E0:01C3C008] > > On Thu, 2003-12-11 at 11:59, Geoff Keating wrote: > > Andrew MacLeod writes: > > > > > I have array of pointers to trees. > > > > > > so > > > > > > tree **defs; > > > > That's an array of pointers to pointers to trees. 'tree' is a pointer > > to a tree. > > > > Depends on how you descibe it. 'tree' is a pointer to a tree > structure/union so Its an array of pointers to pointers to tree > structures, yes, but an array of pointers to trees seemed like a > sufficient description to me... > > regardless, Its a cache of all the operand pointers in the stmt. So its > a list of pointers to trees so we can access/change them easily without > hunting for them. thus 'tree **'. > > So all the trees will get marked when the stmt is marked. Since the > vector is part of the stmt annotation, if the stmt operands are not > marked, the annotation/vector will not get marked either. If the stmt is > marked, I need the vector to be marked, but none of the components. > > So I need the tree ** vector to be treated as if is an array of > interegers or something, no marking of anything in it. Right. gengtype is specifically designed to prevent you from doing this, because it's usually a mistake. For instance: - If you're wrong about the lifetime of the objects, you'll end up with dangling pointers, which GC is supposed to prevent. For instance, if someone rearranges the stmt (maybe by doing some constant folding) and then calls ggc_collect without updating the defs structure. - You cannot save objects like this with PCH. - A future compacting collector will not work if you do this. If you still think this is a good idea, why not just try: intptr_t * defs_p; ? > Im about to punt on it anyway and manage those vectors myself since GC > doesnt seem to want to deal with them nicely. -- - Geoffrey Keating