This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
- From: "dnovillo at google dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 21 Aug 2012 18:19:10 +0000
- Subject: [Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
- Auto-submitted: auto-generated
- References: <bug-54332-4@http.gcc.gnu.org/bugzilla/>
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.