From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5488 invoked by alias); 26 Nov 2001 06:49:28 -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 5466 invoked from network); 26 Nov 2001 06:49:25 -0000 Received: from unknown (HELO www.cgsoftware.com) (208.155.65.221) by sourceware.cygnus.com with SMTP; 26 Nov 2001 06:49:25 -0000 Received: from localhost (localhost [127.0.0.1]) by www.cgsoftware.com (8.9.3/8.9.3) with ESMTP id BAA08636; Mon, 26 Nov 2001 01:49:14 -0500 Date: Fri, 16 Nov 2001 08:32:00 -0000 From: Daniel Berlin To: Fergus Henderson cc: Neil Booth , "gcc@gcc.gnu.org" Subject: Re: ICE in change_address at emit_rtl.c In-Reply-To: <20011126170549.B16173@earth.cs.mu.oz.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-11/txt/msg00727.txt.bz2 On Mon, 26 Nov 2001, Fergus Henderson wrote: > On 24-Nov-2001, Neil Booth wrote: > > I've often wondered whether we might do better type-wise to actually > > use separate types, and refer to them as separate types, rather than > > having every function take an effectively typeless "tree" as input. > > This alone would help type safety quite a bit. > > FWIW I took this approach when writing the Mercury interface to the > GCC "tree" type -- I had separate Mercury types for tree nodes > representing expressions, declarations, types, initializers, etc. > For my purposes this approach worked fairly well. FWIW also (the idea of generating the tree structures using one of the various ast/tree tools around usually comes up in these discussions ) , over the past year, i've tried to rewrite our tree datatype using various AST/tree code producerss (IE kimwitu, ASDL, etc. If it's out there, I've tried it.). Not only to ease serialization, but because most of these tools also let you specify tree walkers/etc in nice forms. They either had limitations that were unacceptable (ASDL's picklers only handle acyclic structures), generated code that was unacceptable (either too many support libs required, not integratable into what we have now without a *lot* of work, etc), or couldn't handle the complex structure we have now in an elegant way. However, today i ran across treecc. It was written by the portable.net people for their c# compiler, but can generate readable C/C++/Java/C# code. Although it doesn't produce code to serialize the structure, the tool is easily modifable to do so (i can actually understand the source code easily, unlike some of the other tools). It also seems to already support most, if not all, of the features we would need to generate our tree structures (tree structure inheritance, abstract bases,and fields that are marked as not required to be passed to the constructor it generates). It also is easy to write the various walkers in, if you wanted to (though it's not required). The resulting c code could stand a little factoring, but that's no biggie to implement. It's not too difficult at all to integrate with what we have now (if it requires any changes at all to start) In other words, it would be a usable tool for the purposes of generating the tree structures gcc uses. First one i've come across. Just thought i'd point it out, Dan > -- > Fergus Henderson | "I have always known that the pursuit > The University of Melbourne | of excellence is a lethal habit" > WWW: | -- the last words of T. S. Garp. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Fergus Henderson Cc: Neil Booth , "gcc@gcc.gnu.org" Subject: Re: ICE in change_address at emit_rtl.c Date: Sun, 25 Nov 2001 22:49:00 -0000 Message-ID: References: <20011126170549.B16173@earth.cs.mu.oz.au> X-SW-Source: 2001-11/msg01231.html Message-ID: <20011125224900.ddX7qmWzDtGG4g1yQk4vm3acdtT1EcB1ss5AT3hJqE0@z> On Mon, 26 Nov 2001, Fergus Henderson wrote: > On 24-Nov-2001, Neil Booth wrote: > > I've often wondered whether we might do better type-wise to actually > > use separate types, and refer to them as separate types, rather than > > having every function take an effectively typeless "tree" as input. > > This alone would help type safety quite a bit. > > FWIW I took this approach when writing the Mercury interface to the > GCC "tree" type -- I had separate Mercury types for tree nodes > representing expressions, declarations, types, initializers, etc. > For my purposes this approach worked fairly well. FWIW also (the idea of generating the tree structures using one of the various ast/tree tools around usually comes up in these discussions ) , over the past year, i've tried to rewrite our tree datatype using various AST/tree code producerss (IE kimwitu, ASDL, etc. If it's out there, I've tried it.). Not only to ease serialization, but because most of these tools also let you specify tree walkers/etc in nice forms. They either had limitations that were unacceptable (ASDL's picklers only handle acyclic structures), generated code that was unacceptable (either too many support libs required, not integratable into what we have now without a *lot* of work, etc), or couldn't handle the complex structure we have now in an elegant way. However, today i ran across treecc. It was written by the portable.net people for their c# compiler, but can generate readable C/C++/Java/C# code. Although it doesn't produce code to serialize the structure, the tool is easily modifable to do so (i can actually understand the source code easily, unlike some of the other tools). It also seems to already support most, if not all, of the features we would need to generate our tree structures (tree structure inheritance, abstract bases,and fields that are marked as not required to be passed to the constructor it generates). It also is easy to write the various walkers in, if you wanted to (though it's not required). The resulting c code could stand a little factoring, but that's no biggie to implement. It's not too difficult at all to integrate with what we have now (if it requires any changes at all to start) In other words, it would be a usable tool for the purposes of generating the tree structures gcc uses. First one i've come across. Just thought i'd point it out, Dan > -- > Fergus Henderson | "I have always known that the pursuit > The University of Melbourne | of excellence is a lethal habit" > WWW: < http://www.cs.mu.oz.au/~fjh > | -- the last words of T. S. Garp. >