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!


  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: link
Be 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).