https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190
--- Comment #4 from Mario Charest <stayprivate at gmail dot com> --- On Mon, May 18, 2020 at 1:09 PM msebor at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190 > > Martin Sebor <msebor at gcc dot gnu.org> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Last reconfirmed| |2020-05-18 > Status|UNCONFIRMED |WAITING > Component|c++ |lto > Ever confirmed|0 |1 > CC| |marxin at gcc dot gnu.org > , > | |msebor at gcc dot gnu.org > Keywords| |documentation > > --- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> --- > Which part do you find surprising? That the warning is issued during the > LTO > stage at all or that -Wno-stringop-overflow can be used during the LTO > stage to > suppress it? > Mostly the LTO stage. I got bitten because I assumed warning came from the compiler. If the LTO stage would have handle #pragma diagnostic i would have never noticed where it came from. > > During LTO the same compiler options should be implicitly enabled as during > ordinary compilation, including warnings. (This presents some challenges > when > the compilation was done with different options for different files.) > Most project with cmake using lto will required tweaking. Typically warning options are specified with add_compiler_options(). Now every warning flags must also be passed to the linker, impossible to know which flag has an effect on the LTO stage or not. > It also means that all the same warnings should be expected to be > implicitly > enabled during LTO that were explicitly enabled during the compilation > stage. > I'd expect to see only "late" warnings during LTO, i.e., those that depend > on > optimization. (I understand this doesn't work completely consistently yet > but > I believe that's the goal.) > > So this effect isn't specific to -Wstringop-overflow, but perhaps it would > be > worth mentioning under -flto? > > -- > You are receiving this mail because: > You reported the bug.