public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dodji at seketeli dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost Date: Thu, 26 Jul 2012 17:16:00 -0000 [thread overview] Message-ID: <bug-53880-4-tvl5qChwPP@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <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!
next prev parent reply other threads:[~2012-07-26 17:16 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-06 15:46 [Bug pch/53880] New: " markus at trippelsdorf dot de 2012-07-06 15:55 ` [Bug pch/53880] " markus at trippelsdorf dot de 2012-07-06 16:47 ` markus at trippelsdorf dot de 2012-07-08 7:08 ` markus at trippelsdorf dot de 2012-07-09 8:41 ` rguenth at gcc dot gnu.org 2012-07-23 13:46 ` paolo.carlini at oracle dot com 2012-07-23 21:29 ` steven at gcc dot gnu.org 2012-07-23 22:46 ` steven at gcc dot gnu.org 2012-07-24 6:50 ` markus at trippelsdorf dot de 2012-07-24 8:16 ` stevenb.gcc at gmail dot com 2012-07-24 9:20 ` steven at gcc dot gnu.org 2012-07-24 9:34 ` rguenth at gcc dot gnu.org 2012-07-24 9:41 ` stevenb.gcc at gmail dot com 2012-07-24 9:43 ` rguenth at gcc dot gnu.org 2012-07-24 10:03 ` stevenb.gcc at gmail dot com 2012-07-24 10:13 ` paolo.carlini at oracle dot com 2012-07-26 16:30 ` dodji at seketeli dot org 2012-07-26 17:15 ` dodji at seketeli dot org 2012-07-26 17:16 ` dodji at seketeli dot org 2012-07-26 17:16 ` dodji at seketeli dot org [this message] 2012-07-26 17:18 ` dodji at seketeli dot org 2012-07-26 19:45 ` stevenb.gcc at gmail dot com 2012-07-26 21:11 ` dodji at seketeli dot org 2012-07-30 9:11 ` steven at gcc dot gnu.org 2012-07-30 10:54 ` markus at trippelsdorf dot de 2012-07-30 11:08 ` steven at gcc dot gnu.org 2012-07-30 11:22 ` markus at trippelsdorf dot de 2012-07-30 12:03 ` steven at gcc dot gnu.org 2012-07-30 13:17 ` steven at gcc dot gnu.org 2012-07-30 13:52 ` steven at gcc dot gnu.org 2012-07-30 14:22 ` steven at gcc dot gnu.org 2012-07-30 15:04 ` steven at gcc dot gnu.org 2012-07-30 16:15 ` steven at gcc dot gnu.org 2012-07-30 16:26 ` markus at trippelsdorf dot de 2012-07-30 22:55 ` steven at gcc dot gnu.org 2012-07-31 9:21 ` steven at gcc dot gnu.org 2012-07-31 9:24 ` steven at gcc dot gnu.org 2012-07-31 10:36 ` markus at trippelsdorf dot de
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-53880-4-tvl5qChwPP@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).