[Bug c++/14179] [3.3/3.4/4.0 Regression] out of memory
mark at codesourcery dot com
gcc-bugzilla@gcc.gnu.org
Wed Sep 22 15:54:00 GMT 2004
------- Additional Comments From mark at codesourcery dot com 2004-09-22 15:54 -------
Subject: Re: [3.3/3.4/4.0 Regression] out of memory
paolo dot bonzini at polimi dot it wrote:
> and the operator-precedence was placed on the
>wiki a week ago as a generic "speedup area", not a project that is
>actively worked on unlike Matt's lexer overhaul:
>
>
Honestly, we didn't know we'd be working on until the early part of this
week. We didn't decided until Monday around noon in California. But,
the fundamental point is that it's in nobody's best interest to
duplicate work, so we will try to make as much noise as possible about
projects.
>http://www.dberlin.org/gccwiki/index.php/Speedup%20areas
>
>Since that page also mentions Nathan's "Add contains-repeated-base and
>is diamond-shaped flags to classes" project, maybe it is *that* page
>that needs to be louder.
>
>
Just for the record, I do not know if Nathan is presently working on
that or not. I think he may have concluded there is not enough win there.
> > We'll try to be louder.
>
>No problem. You're doing a good work.
>
>
Thanks for your understanding -- and you, likewise, are doing good work!
After you get timing numbers for 14179, it would be interesting to
consider whether or not we should try to extend the operator-precedence
parser, or do other short-circuiting tricks, when getting down to the
bottom of binary expressions. For example, if a unary expression is an
integer literal or identifier followed by ")" or "," or ";" we know that
it's just a primary expression. In other words, we could use two tokens
of lookahead to zip straight to cp_parser_primary_expression. Would you
like to take a look at that as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
More information about the Gcc-bugs
mailing list