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.
