On Fri, Aug 29, 2014 at 07:16:55PM +0200, Manuel López-Ibáñez wrote:
> On 19 August 2014 00:06, Joseph S. Myers <jos...@codesourcery.com> wrote:
> > On Tue, 12 Aug 2014, Marek Polacek wrote:
> >
> >> This then is the version with both issues fixed (and new test).
> >>
> >> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >>
> >> 2014-08-12 Marek Polacek <pola...@redhat.com>
> >>
> >> gcc/c-family/
> >> * c-opts.c (sanitize_cpp_opts): Make warn_long_long be set according
> >> to warn_c90_c99_compat.
> >> * c.opt (Wc90-c99-compat, Wdeclaration-after-statement): Initialize
> >> to -1.
Sorry for the delay.
> To be honest, I consider this a small step back towards encoding all
> the options dependencies in the *.opt files.
>
> If I understand correctly, the reason for initializing
> Wdeclaration-after-statement to -1 is to detect whether the option has
> been enabled/disabled explicitly and, if not, then only emit the
> warning if Wpedantic or Wc90-c99-compat has been given, This is
> precisely what LangEnabledBy was designed for. The problem in this
> case is that we only want to enable Wdeclaration-after-statement when
> given Wpedantic if !flag_isoc99 and currently there is not way to
> encode this with LangEnabledBy.
Yeah, this is my understanding.
> Perhaps we need a LangEnabledByIf(C ObjC,Wpedantic,!flag_isoc99). I
> see two difficulties for implementing this:
>
> * We would need to handle warning options after -std=.
> * We would need to have access to flag_isoc99 in the generated file
> options.c. I think this flag is not encoded in global_opts, thus we
> could pass it as an argument to C_handle_option_auto.
>
> Is this the direction we want to move towards? Perhaps it is not worth
> the trouble just for the handful of options that would require such
> LangEnabledByIf().
I'd say it's not worth it. As you say, we only have a few of those
and I'm not sure the gain would offset the cost.
Marek
