[Bug c++/14179] [3.3/3.4/4.0 Regression] out of memory

["mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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