[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