[v2] c-family: Enable -fpermissive for C and ObjC
Checks
Commit Message
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.
---
v2: Rebased after David's m_* member changes. Still no test suite
regressions. Actual tests will need some C permerrors, which
we do not yet have.
gcc/c-family/c-opts.cc | 6 ++++++
gcc/c-family/c.opt | 2 +-
gcc/doc/invoke.texi | 8 ++++++--
3 files changed, 13 insertions(+), 3 deletions(-)
base-commit: 3cc9ad41db87fb85b13a56bff1f930c258542a70
Comments
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
@@ -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";
}
@@ -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
@@ -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