Re: [PATCH] add -Wstringop-overflow to LTO options (PR 84212)

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Feb 8, 2018 at 4:08 AM, Martin Sebor <msebor@gmail.com> wrote:
> I went ahead and changed all the options on the list below
> to include LTO and tested the attached patch by configuring
> with --with-build-config=bootstrap-lto --disable-werror and
> making profiledbootstrap.  Attached, besides the patch, is
> also the breakdown of warnings.  The interesting column is
> the one labeled Unique.  It gives the number of distinct
> instances of each warning.
>
> This was with all languages but Go and Brig.  Those two fail
> what seem like unrelated reasons.  The Brig error is some
> unsatisfied reference (I lost the log).  Go fails with
> a bunch of errors looking like this, one for each errno
> constant:
>
> /opt/notnfs/msebor/src/gcc/84212/libgo/go/syscall/env_unix.go:96:10: error:
> reference to undefined name ‘EINVAL’
>
> On 02/07/2018 12:30 PM, Martin Sebor wrote:
>>
>> In PR 84212 the reporter asks why -Wno-stringop-overflow has
>> no effect during LTO linking.  It turns out that the reason
>> is the same as in bug 78768: the specification in the c.opt
>> file is missing LTO among the languages.
>>
>> The attached patch adds LTO to it and to -Wstringop-truncation.
>>
>> Bootstrapped and regtested on x86_64-linux.
>>
>> There are other middle-end options in the c.opt file that do
>> not mention LTO that arguably should (*).  I didn't change
>> those in this patch, in part because I don't have test cases
>> showing where it matters, and in part because I don't think
>> that having to remember to include LTO in these options (and,
>> ideally, also include a test in the test suite for each) is
>> a good approach.
>>
>> It seems that including LTO implicitly for all options would
>> obviate this manual step and eliminate the risk of missing
>> them.  Is there a reason not to do that?
>>
>> If implicitly including LTO for every option is not feasible,
>> then it might be worthwhile to write a small script to verify
>> that every middle-end option does mention LTO, and have make
>> run the script as part of the self-test step.

Well, in principle middle-end options belong in common.opt
and should be marked 'Common'.

But obviously the ones listed do not apply to, say, Fortran
but with adding LTO mixed language TUs can get late
warnings from LTO.  But they also get late warnings for
the Fortran parts then.

So related is some other PR which mentions that we do not
save warning options in the LTO IL and thus keep their
setting properly attached to function state.  I guess we should
revisit this at least for LTO supported ones.

Patch is ok.

>> Is there support for either of these changes?  If not, are
>> there any other ideas for how to avoid these kind of bugs?
>>
>> Martin
>>
>> [*] Here are a few examples.  I'm fine with adding LTO to
>> any or all of these as well as any others that I may have
>> missed for GCC 8 if that sounds like a good idea.
>>
>>   -Walloc-size-larger-than
>>   -Warray-bounds
>>   -Wformat-truncation=
>>   -Wmaybe-uninitialized
>>   -Wnonnull
>>   -Wrestrict
>>   -Wstrict-overflow
>>   -Wsuggest-attribute
>>   -Wuninitialized
>
>