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