Help ! Frozen by a comment in gcc/c-common.h!
Hi All!
While modifying the C lexer to accommodate it for experimental
C-derived language front-end, I've stumbled across the following
comment in gcc/c-common.h before the "enum rid" definition (still
there in gcc-4.5-20090820 snapshot):
42 /* Reserved identifiers. This is the union of all the keywords for C,
43C++, and Objective-C. All the type modifiers have to be in one
44block at the beginning, because they are used as mask bits. There
45are 27 type modifiers; if we add many more we will have to redesign
46the mask mechanism. */
47
48 enum rid
49 {
50 /* Modifiers: */
51 /* C, in empirical order of frequency. */
52 RID_STATIC = 0,
53 RID_UNSIGNED, RID_LONG,RID_CONST, RID_EXTERN
...
Could you please enlighten me -- is the comment still relevant? If so,
where the usage of type modifiers entries in enum rid as mask bits can
be seen in gcc code (or documentation, if applicable)?
I'd like to be aware, since I've defined several (four) additional type
modifiers.
Thanks in advance,
Alexei I. Adamovich
Re: Help ! Frozen by a comment in gcc/c-common.h!
Hi! On Thu, Aug 27, 2009 at 09:51:30AM -0700, Ian Lance Taylor wrote: > I suspect that that comment is no longer relevant. At least, I can't > seem to find the mask. Perhaps somebody else knows. I got. Since no anybody more has commented, let us be sure that the mask mechanism has gone. [I've recently found corresponding bit mask in gcc-3.3.6 in grokdeclarator (c-decl.c), e.g: > 3589 if (i == RID_LONG && (specbits & (1 << (int) RID_LONG))) or > 3624 specbits |= 1 << (int) i; where > 3586 enum rid i = C_RID_CODE (id); ] So for the sake of those who will develop C-derived front ends, should we change the comment like below: > /* Reserved identifiers. This is the union of all the keywords for C, >C++, and Objective-C. In the past, in earlier GCC versions all the >type modifiers had to be in one block at the beginning, because >they were used as mask bits. There were 27 type modifiers; so if >anybody added many more the mask mechanism would have to be >redesigned. Now it doesn't matter, since corresponding mask > machinery gone */ Should I (or you) submit a patch? Alexei I. Adamovich
A question about GGC/gengtype
Hi, all!
I have a question concerning GGC and gengtype in particular.
The question is: can I have DIFFERENT <>-ed types and
variables with the SAME NAMES in two DIFFERENT front ends?
More expanded: I am trying to implement a front-end of a C-derived
language (say, Z); and have used the c-parser.c as a base for the
source code of z-parser.c. Of course, I need to add the new "Z"
variants of grammatical rules, and, when doing so, I don't want to
deal with Objective-C (and OpenMP) parts of parser code. So I have
eliminated most of ObjC/OpenMP-related functions and fragments.
Now I am looking at c_parser/the_parser definitions [near
c-parser.c:L168]:
] typedef struct GTY(()) c_parser {
] /* The look-ahead tokens. */
] c_token tokens[2];
] /* How many look-ahead tokens are available (0, 1 or 2). */
] ...
] BOOL_BITFIELD lex_untranslated_string : 1;
] /* Objective-C specific parser/lexer information. */
] BOOL_BITFIELD objc_pq_context : 1;
] /* The following flag is needed to contextualize Objective-C lexical
] analysis. In some cases (e.g., 'int NSObject;'), it is
] undesirable to bind an identifier to an Objective-C class, even
] if a class with that name exists. */
] BOOL_BITFIELD objc_need_raw_identifier : 1;
] } c_parser;
]
]
] /* The actual parser and external interface. ??? Does this need to be
]garbage-collected? */
]
] static GTY (()) c_parser *the_parser;
So I want to remove this objc_pq_context and objc_needed_raw fields of
struct c_parser. But I don't want to rename c_parser/the_parser
type/variable since this will add a lot of changes (additional places
to worry about when porting to new GCC version).
So, please, answer: can I don't worry leaving these two GTY-ed
(c_parser/the_parser) with their own names in my "Z" front end?
Thanks in advance!
