Re: I think I found a bug in the optimizer...

[Zack Weinberg <zack at wolery dot cumb dot org>]

On Sun, Feb 27, 2000 at 07:12:31PM -0800, Zack Weinberg wrote:
> 
> No, it's definitely cc1.  I can reproduce this quite easily on my
> system.  It's just tied into knots building a parse tree for this
> monster expression.  We don't ever even get to rest_of_compilation.

To follow up: I kicked out everything else in memory and let the
compile run to completion.  Here's the statistics:

 __strcpy_small __strcspn_c1 __strcspn_c2 __strcspn_c3 __strspn_c1
 __strspn_c2 __strspn_c3 __strpbrk_c2 __strpbrk_c3 __strtok_r_1c
 __strsep_1c __strsep_2c __strsep_3c __strsep_g get_unix_info 
 {GC 357018k -> 9480k in 0.310}
time in parse: 36.840000 (74%)
time in jump: 6.060000 (12%)
[all other passes <2% each]

3:10.22 - 45.03u, 4.45s, 26% - 80192/230866

357018k is just under 349 Mb of core - which is far too much.  But
note that it all got thrown away on the very first GC pass; I doubt
the mess ever even got to the RTL level.

The sad part is, the assembly dump at -O2 is identical with and
without -D__NO_STRING_INLINES.

zw