Re: backport fix for PR 82063 to GCC 7 and 8

[Martin Sebor <msebor at gmail dot com>]

On 06/07/2018 03:17 PM, Jakub Jelinek wrote:
> On Thu, Jun 07, 2018 at 02:56:13PM -0600, Martin Sebor wrote:
> > As I mentioned in my reply to Jeff below, I'd like to backport
> > the fix for PR 82063 to the two release branches, GCC 7 and 8.
> > If there are no concerns/objections I'll go ahead and commit
> > the patch to both sometime next week.
> >
> >   https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01822.html
>
> This results in -Wno-no-alloc-size-larger-than being accepted, I don't think
> that is desirable (at least if any warnings are emitted).
> Short testcase:
> echo 'int foo (void) { int i; return i; }' > test.c
> ./xgcc -B ./ -Wno-no-alloc-size-larger-than -Wuninitialized test.c
> So I think you want RejectNegative on that option.

Good catch, thanks!

Though accepting -Wno-no- seems to a general bug in the driver
for all options that don't specify RejectNegative.  It accepts
-Wno-no-all as well.  In fact, it seems to accept anything that
starts with -Wno-, even if it's completely bogus.

> Also, the option is not documented in doc/invoke.texi, it is just mentioned
> in description of the -Walloc-size-larger-than= option, that is not enough;
> it needs to be listed in the Warning Options list, and it should have
> @itemx next to -Walloc-size-larger-than=.

Adding @itemx will just add a index entry for it, right?  That
makes sense.

I'm not sure I agree that the negative form should be listed
in @gccoptlist{}.  Only options that are on by default mention
the -Wno- form there so including both forms would go against
this convention.

> What about the other -W...-larger-than options?
> Don't you want also -Wno-alloca-larger-than and -Wno-vla-larger-than ?
> What about -Wno-frame-larger-than and -Wno-larger-than?

I'd like add the same suffix handling for these options as well,
but I assume it's appropriate only for GCC 9.  I started looking
into moving it to where it can be used by all these options but
got sidetracked by other things.  While working on it I came
across a cl_host_wide_int flag that suggests that some support
for option arguments larger than int already exists.

> I'm not convinced backporting the addition of the new options to release
> branches is desirable, fixing the bug in alloc_max_size is ok for the
> branches.

I agree.  (Or did you mean to include -Wno-alloc-size-larger-than
among the new options?)

Let me add the RejectNegative and the @itemx bit and backport
it next week.

Martinm