https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #3) > DARWIN_REGISTER_TARGET_PRAGMAS registers 5. > If I count well on Linux and yesterday's trunk, for -fopenmp -fopenacc > -fcilkplus I see 10 OpenACC, 25 OpenMP, 2 Cilk+ and 22 other deferred > pragmas being registered, if you add 5 to that it is 64. > The comment in c-family is clearly outdated, the C parser uses 8 bits for > pragma_kind. > But, looking at parser.h, I see > /* The kind of token. */ > ENUM_BITFIELD (cpp_ttype) type : 8; > /* If this token is a keyword, this value indicates which keyword. > Otherwise, this value is RID_MAX. */ > ENUM_BITFIELD (rid) keyword : 8; > /* Token flags. */ > unsigned char flags; > /* Identifier for the pragma. */ > ENUM_BITFIELD (pragma_kind) pragma_kind : 6; > /* True if this token is from a context where it is implicitly extern "C" > */ > BOOL_BITFIELD implicit_extern_c : 1; > /* True if an error has already been reported for this token, such as a > CPP_NAME token that is not a keyword (i.e., for which KEYWORD is > RID_MAX) iff this name was looked up and found to be ambiguous. */ > BOOL_BITFIELD error_reported : 1; > /* True for a token that has been purged. If a token is purged, > it is no longer a valid token and it should be considered > deleted. */ > BOOL_BITFIELD purged_p : 1; > which if I count well is already 33 bits anyway, followed by 32-bit integer > and pointer, therefore on 64-bit hosts there are 63 bits of padding and on > 32-bit hosts 31 bits of padding. That should be fixed of course. Maybe some unioning can be done as well based on 'type' (keyword?)
