Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
From: Adriaan van Os
Subject: the loss of SET_TYPE
Date: 26 Mar 2006, 08:43:48
Forwarding from the gcc-patches mailing list > Gaius Mulley wrote: >> I'm trying to port bring the GNU Modula-2 front end up to gcc-4.1.0 >> and have found out that SET_TYPE has been removed :-) >> >> I see the patch from Dec 2004: >> >> http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00670.html >> >> and understand the reason (no front ends in gcc tree use SET_TYPE >> etc). I suppose I'd just like to flag that Modula-2 utilises this type >> during the generation of BITSET types and also large sets (built >> internally from multiple int length SET_TYPEs). But I totally >> understand it might be difficult to justify code which is never run >> (and difficult to test) in the main gcc tree.. >> >> Pragmatically I guess it is best for me to maintain a reversed patch >> which can be applied to a gcc-4.1.0 tar ball which reintroduces this >> TYPE. Any thoughts? > > Many of the front-ends use langauge-specific tree codes to manipulate > types and/or operators specific to their needs. I suspect that > treating the SET_TYPE as a front-end tree is your best bet, and > lowering > it to the appropriate C-like representation (array, struct or integer) > during gimplification is the best way to go. > > Even if SET_TYPE is resurected, I suspect that the lack of constant > folding transformations on these expressions/trees, makes it > unnecessary > to expose their semantics to the early middle-end (and thereby all > other > front-ends), but perhaps there are dwarf2 or similar issues that don't > yet have the necessary hooks, that require this be a "common" tree > code? > > > [As a one-time Modula-2 programmer myself, I'd support Eric's > suggestion. > Wasn't James Morrison investigating issues of GNU pascal integration?] > > Roger Regards, Adriaan van Os
Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.
Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.
This page was created by Crystal 0.999 (Linux 2.4.27/i686).