From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-397260-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8389 invoked by alias); 24 Jul 2012 10:03:21 -0000
Received: (qmail 8379 invoked by uid 22791); 24 Jul 2012 10:03:20 -0000
X-SWARE-Spam-Status: No, hits=-4.3 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Jul 2012 10:03:06 +0000
From: "stevenb.gcc at gmail dot com" <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: Tue, 24 Jul 2012 10:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: pch
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: stevenb.gcc at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-53880-4-Tnxsc652NW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53880-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53880-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2012-07/txt/msg01846.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880

--- Comment #13 from stevenb.gcc at gmail dot com <stevenb.gcc at gmail dot com> 2012-07-24 10:03:05 UTC ---
On Tue, Jul 24, 2012 at 11:42 AM, rguenth at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> The pointer to the array, but not the array elements.  So it's pointless
> to know the length and
>
>    souce_location * macro_locations;
>
> should still rewrite the pointer itself, no?

Hmm.  I'm not sure. Without the annotation, how does the PCH machinery
know how long that array is? OTOH there isn't anything else, other
than those dead loops, that looks at h.n_tokens.

Perhaps there should be a warning from gengtype if the length
attribute is applied to a scalar type.