This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: the loss of SET_TYPE


Roger Sayle <roger@eyesopen.com> writes:

> On 25 Mar 2006, 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.

Hi,

yes, this could be done. The large set types are built up of a struct
containing consecutive int sized sets - but GNU Modula-2 uses SET_TYPE
rather than unsigned int since the SET_TYPE provides useful
debugging information..

> 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?

the dwarf2 SET_TYPE debugging info is pretty useful - especially when
combined with a patched gdb as SET OF CHAR, SET OF [-100..100] all may
be gdb 'ptype'd and gdb 'print'ed.  I'll look into gimple to see
whether it is possible, say, to treat all BITSET types as unsigned
ints and tell gimple (and dwarf2 and friends) to output SET_TYPE dies
from within the language front end via various call back routines maybe?

> [As a one-time Modula-2 programmer myself, I'd support Eric's suggestion.
> Wasn't James Morrison investigating issues of GNU pascal integration?]

excellent news, thanks! I'll read up about the GNU Pascal integration..

regards,
Gaius


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]