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

Martin Sebor msebor@gmail.com
Wed Feb 7 19:31:00 GMT 2018


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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-84212.diff
Type: text/x-patch
Size: 2590 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20180207/076e14ef/attachment.bin>


More information about the Gcc-patches mailing list