Message ID | 874jhzgemo.fsf@oldenburg.str.redhat.com |
---|---|
State | New |
Headers | show |
Series | [v2] c-family: Enable -fpermissive for C and ObjC | expand |
On Mon, Nov 06, 2023 at 03:06:39PM +0100, Florian Weimer wrote: > Future changes will treat some C front end warnings similar to > -Wnarrowing. > > gcc/ > > * doc/invoke.texi (Warning Options): Mention C diagnostics > for -fpermissive. > > gcc/c-family/ > > * c.opt (fpermissive): Enable for C and ObjC. > * c-opts.cc (set_std_c89): Enable -fpermissive. Won't this set flag_permissive even for -std=c89 -std=c99 ? Haven't tried, but if set_std_c* is called multiple times if more than one -std= option appears, then perhaps this should be done later after processing all options, not during that processing. Jakub
* Jakub Jelinek: > On Mon, Nov 06, 2023 at 03:06:39PM +0100, Florian Weimer wrote: >> Future changes will treat some C front end warnings similar to >> -Wnarrowing. >> >> gcc/ >> >> * doc/invoke.texi (Warning Options): Mention C diagnostics >> for -fpermissive. >> >> gcc/c-family/ >> >> * c.opt (fpermissive): Enable for C and ObjC. >> * c-opts.cc (set_std_c89): Enable -fpermissive. > > Won't this set flag_permissive even for -std=c89 -std=c99 ? > Haven't tried, but if set_std_c* is called multiple times if more than > one -std= option appears, then perhaps this should be done later after > processing all options, not during that processing. Ugh, you are right. What would be the right place to do this kind of final option processing? Where those SET_OPTION_IF_UNSET are? Thanks, Florian
On Mon, Nov 06, 2023 at 03:19:32PM +0100, Florian Weimer wrote: > * Jakub Jelinek: > > > On Mon, Nov 06, 2023 at 03:06:39PM +0100, Florian Weimer wrote: > >> Future changes will treat some C front end warnings similar to > >> -Wnarrowing. > >> > >> gcc/ > >> > >> * doc/invoke.texi (Warning Options): Mention C diagnostics > >> for -fpermissive. > >> > >> gcc/c-family/ > >> > >> * c.opt (fpermissive): Enable for C and ObjC. > >> * c-opts.cc (set_std_c89): Enable -fpermissive. > > > > Won't this set flag_permissive even for -std=c89 -std=c99 ? > > Haven't tried, but if set_std_c* is called multiple times if more than > > one -std= option appears, then perhaps this should be done later after > > processing all options, not during that processing. > > Ugh, you are right. > > What would be the right place to do this kind of final option > processing? Where those SET_OPTION_IF_UNSET are? c_common_post_options ? Generally, we have global_options, which are the values of the options (implicit or explicit) and then another variable of the same type, global_options_set, which uses all values just as booleans whether the option was set explicitly or not. Jakub
* Jakub Jelinek: > On Mon, Nov 06, 2023 at 03:19:32PM +0100, Florian Weimer wrote: >> * Jakub Jelinek: >> >> > On Mon, Nov 06, 2023 at 03:06:39PM +0100, Florian Weimer wrote: >> >> Future changes will treat some C front end warnings similar to >> >> -Wnarrowing. >> >> >> >> gcc/ >> >> >> >> * doc/invoke.texi (Warning Options): Mention C diagnostics >> >> for -fpermissive. >> >> >> >> gcc/c-family/ >> >> >> >> * c.opt (fpermissive): Enable for C and ObjC. >> >> * c-opts.cc (set_std_c89): Enable -fpermissive. >> > >> > Won't this set flag_permissive even for -std=c89 -std=c99 ? >> > Haven't tried, but if set_std_c* is called multiple times if more than >> > one -std= option appears, then perhaps this should be done later after >> > processing all options, not during that processing. >> >> Ugh, you are right. >> >> What would be the right place to do this kind of final option >> processing? Where those SET_OPTION_IF_UNSET are? > > c_common_post_options ? > Generally, we have global_options, which are the values of the options > (implicit or explicit) and then another variable of the same type, > global_options_set, which uses all values just as booleans whether the > option was set explicitly or not. Yes, c_common_post_options seems to work. Thanks for the hint regarding global_options_set. I can use it to make -std=gnu89 -fno-permissive do something useful. I'm going to send an update patch. Florian
diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc index a980912f7e1..dbf92be9698 100644 --- a/gcc/c-family/c-opts.cc +++ b/gcc/c-family/c-opts.cc @@ -1711,6 +1711,12 @@ set_std_c89 (int c94, int iso) flag_isoc99 = 0; flag_isoc11 = 0; flag_isoc2x = 0; + /* -std=gnu89 etc. should not override -pedantic-errors. */ + if (!global_dc->m_pedantic_errors) + { + flag_permissive = 1; + global_dc->m_permissive = 1; + } lang_hooks.name = "GNU C89"; } diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt index 29d3d789a49..cc3a6610148 100644 --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -2112,7 +2112,7 @@ C ObjC C++ ObjC++ Look for and use PCH files even when preprocessing. fpermissive -C++ ObjC++ Var(flag_permissive) +C ObjC C++ ObjC++ Var(flag_permissive) Downgrade conformance errors to warnings. fplan9-extensions diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 6e776a0faa1..dfa01220b93 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -6170,13 +6170,17 @@ errors by @option{-pedantic-errors}. For instance: Downgrade some required diagnostics about nonconformant code from errors to warnings. Thus, using @option{-fpermissive} allows some nonconforming code to compile. Some C++ diagnostics are controlled -only by this flag, but it also downgrades some diagnostics that have -their own flag: +only by this flag, but it also downgrades some C and C++ diagnostics +that have their own flag: @gccoptlist{ -Wnarrowing @r{(C++)} } +The @option{-fpermissive} option is the default for historic C language +modes (@option{-std=c89}, @option{-std=gnu89}, @option{-std=c90}, +@option{-std=gnu90}). + @opindex Wall @opindex Wno-all @item -Wall