This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost


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

--- Comment #18 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-07-26 17:18:34 UTC ---
> --- 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.

As I said in a previous comment, I'd say no length attribute should even
be needed here.  In this particular case, no empty loop would have been
generated in the first place.

I would still apply the patch that you cooked (and mentioned in another
comment) to be sure we don't get bitten by such empty loops being
otherwise generated.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]