This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
- From: "dodji at seketeli dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 26 Jul 2012 17:15:43 +0000
- Subject: [Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
- Auto-submitted: auto-generated
- References: <bug-53880-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #16 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-07-26 17:15:15 UTC ---
"rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a Ãcrit:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
>
> --- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-24 09:34:21 UTC ---
> Err, isn't the GTY annotation in
>
> as y1. x0 is the spelling location for the argument token "1",
> and x2 is the spelling location for the argument token "2". */
> source_location * GTY((length ("2 * %h.n_tokens"))) macro_locations;
>
> simply pointless?
In theory, I would say yes it should be pointless.
But in practise, it looks like the "gengtype code output system" needs a
length annotation for it because macro_location is a pointer to
something that is not a struct, basically.
Otherwise, calling gengtype on the resulting gtype.state yields:
gcc/fix-master/gcc/../libcpp/include/line-map.h:168: field
`(*x).info_ordinary.maps[i0].d.macro.macro_locations' is pointer to
unimplemented type
This is because with no annotation, the information for
"macro_locations" that we have in the generated gtype.state is:
(!pair "macro_locations"
(!type already_seen 6)
(!srcfileloc "../libcpp/include/line-map.h" 168)
nil)
With the gengtype length annotation, we have:
(!pair "macro_locations"
(!type already_seen 6)
(!srcfileloc "../libcpp/include/line-map.h" 168)
(!options
(!option length string "2 * %h.n_tokens")))
The important thing to notice there is that in the latest case, there is
a "length" option (or attribute) that is present in the description.
Then looking at the walk_type function in gengtype.c, we see:
case TYPE_POINTER:
{
...
if (!length)
{
if (!UNION_OR_STRUCT_P (t->u.p)
&& t->u.p->kind != TYPE_PARAM_STRUCT)
{
error_at_line (d->line,
"field `%s' is pointer to unimplemented type",
d->val);
break;
}
...
The 'length' variable not being set to zero there is a consequence of no
gengtype length annotation being present in the line-map.h source code.
So my question would be, why is gengtype forcing pointers to e.g,
scalars to have a length annotation?
If this wasn't the case, I think the expensive empty loops wouldn't be
generated in the first place, would they?
--- Comment #17 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-07-26 17:15:43 UTC ---
> --- Comment #14 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-07-24 10:13:24 UTC ---
> Thanks Steven for looking into this!
Indeed, thank you Steven!