This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 10 Nov 2015 11:35:51 +0000
- Subject: [Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
- Auto-submitted: auto-generated
- References: <bug-68271-4 at http dot gcc dot gnu dot org/bugzilla/>
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?)