[PATCH]: New warning option -Walloca

Manuel López-Ibáñez lopezibanez@gmail.com
Thu Sep 20 19:40:00 GMT 2007


The fuzzy rule is to wait at least one week between pings. However...

Patches that fix bugs may take weeks to be reviewed. Low urgency
patches may take months. Moreover, I don't think anybody is going to
review this patch soon since it has zero chance to be committed before
GCC 4.3 is branched and trunk is open for GCC 4.4. This is because we
are in stage3. [1] People are busy fixing bugs.

Thus, I would suggest to add the patch to the patch tracker [2] and
then ping about it once GCC 4.3 is released.

Also, you don't need to include the patch every time, just a link to
the mail archive.

Cheers,

Manuel.

[1] http://gcc.gnu.org/ml/gcc/2007-09/msg00286.html
Read about stage3 in http://gcc.gnu.org/develop.html
[2] http://gcc.gnu.org/wiki/GCC_Patch_Tracking

On 20/09/2007, Raksit Ashok <raksit.ashok@gmail.com> wrote:
> Its been 2 days without a response.. just a polite prod.. :)
>
> cheers,
> raksit
>
> ---------- Forwarded message ----------
> From: Raksit Ashok <raksit.ashok@gmail.com>
> Date: Sep 18, 2007 5:48 PM
> Subject: Re: [PATCH]: New warning option -Walloca
> To: Manuel López-Ibáñez <lopezibanez@gmail.com>
> Cc: gcc-patches@gcc.gnu.org
>
>
> On 9/18/07, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
> > > Keeping warn_disallowed_function_p() in opts.c (instead of
> > > c-common.c), and handling this new option in opts.c (instead of
> > > c-opts.c) makes the code a lot cleaner. This is because all this new
> > > code shares some common definitions (DEF_VEC_P of char_p), and
> > > functions (the refactored add_comma_separated_to_vector() function)
> > > with the -finstrument-functions-exclude* handling code in opts.c
> > >
> > > But if you feel strongly about moving warn_disallowed_function_p() to
> > > c-common.c, and handling the option in c-opts.c, I will make the
> > > changes you suggested.
> > >
> >
> > I see now why it could be less cleaner and I don't have a good
> > solution for that. Then, you shouldn't move the option definition to
> > c.opt either.
> >
> > Cheers,
> >
> > Manuel.
>
> Ok, this iterations keeps the new warning in common.opt and the
> supporting functions/definitions in opts.c, but I did make changes as
> per your other suggestions.
>
> How does it look now to you (and others who can approve/reject).. ?
>
> Thanks,
> Raksit
>
> 2007-09-18  Raksit Ashok <raksit.ashok@gmail.com>
>
>       * doc/invoke.texi (Option Summary): Mention new option
>       -Wdisallowed-function-list=...
>       (Warning Options): Document -Wdisallowed-function-list=...
>       * common.opt (Wdisallowed-function-list=): New flag.
>       * flags.h (warn_disallowed_functions): External definition of new
>       boolean warning flag.
>       (warn_if_disallowed_function_p): Declare new function.
>       * opts.c (warning_disallowed_functions): New static variable.
>       (warn_disallowed_functions): New boolean warning flag.
>       (warn_if_disallowed_function_p): New function.
>       (add_comma_separated_to_vector): Rename
>       add_instrument_functions_exclude_list to this.
>       (common_handle_option): Handle new option. Rename calls to
>       add_instrument_functions_exclude_list into calls to
>       add_comma_separated_to_vector.
>       * c-parser.c (c_parser_postfix_expression_after_primary): New warning
>       based on flag warn_disallowed_functions.
>
>
> gcc/cp/ChangeLog
>
> 2007-09-18  Raksit Ashok <raksit.ashok@gmail.com>
>
>       * parser.c (cp_parser_postfix_expression): New warning based on flag
>       warn_disallowed_functions.
>
>
> gcc/testsuite/ChangeLog
>
> 2007-09-18  Raksit Ashok <raksit.ashok@gmail.com>
>
>       * gcc.dg/wdisallowed-functions-1.c: New test.
>       * gcc.dg/wdisallowed-functions-2.c: New test.
>       * g++.dg/warn/Wdisallowed-functions-1.C: New test.
>       * g++.dg/warn/Wdisallowed-functions-2.C: New test.
>
>



More information about the Gcc-patches mailing list