[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

["dnovillo at google dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #17 from dnovillo at google dot com <dnovillo at google dot com> 2012-08-21 18:19:10 UTC ---
On 2012-08-21 14:08 , hjl.tools at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>
> --- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> 2012-08-21 18:08:49 UTC ---
> There are:
>
> opts.c:typedef char *char_p; /* For DEF_VEC_P.  */
> opts.c:DEF_VEC_P(char_p);
> opts.c:DEF_VEC_ALLOC_P(char_p,heap);
> opts-global.c:typedef const char *const_char_p; /* For DEF_VEC_P.  */
> opts-global.c:DEF_VEC_P(const_char_p);
> opts-global.c:DEF_VEC_ALLOC_P(const_char_p,heap);
>
> Will they cause problems if other files define similar types?
>

They shouldn't.  DEF_VEC_* expands to a NOP now.  The allocation 
strategy is only needed during the actual allocation call.  So, in the 
case of opts.c, that would be in add_comma_separated_to_vector() (the 
call to VEC_safe_push).

Those two vectors are only used for -finstrument-options..., though.  So 
that does not seem related.

The call to postpone_unknown_option_warning in opts-global.c seems also 
unrelated.  It's only used when processing unknown options.  That vector 
is popped when the unknown options are freed, so that can't be it either.