https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #11 from Martin Sebor <msebor at gcc dot gnu.org> --- Here's some history. When -Wstringop-overflow was introduced it only detected overflow in calls to C functions like strcpy or memcpy that aren't normally seen in FORTRAN programs. It provided a means of controlling warnings issued by _FORTIFY_SOURCE for overflowing calls to string functions like strcpy. But _FORTIFY_SOURCE misses many buffer overflows and so the warning was enhanced to detect some of those. Because like all flow-based warnings, -Wstringop-overflow has a non-zero rate of false positives, it was meant to be enabled only for the languages where such calls were normally made directly. It was only recently that the warning has also started detecting overflow by assignments. That was done partly because GCC itself transforms calls to library functions like strcpy or memcpy to direct assignments via MEM_REF, which previously prevented buffer overflows by those assignments from being detected. LTO builds are known to have issues with interpreting command line options, including warnings (e.g., merging options used to compile different translation units when functions defined in those units are inlined into one another). I don't know all the details here but I do know it's a topic of ongoing discussion. One solution/workaround I've heard suggested is specifying the expected options when linking. Does passing -Wno-stringop-overflow when linking (with LTO) suppress the warnings? If this warning is useful even in FORTRAN despite the non-zero false positive rate, or maybe because of it with LTO, the option can be made generic so the false positives can be suppressed using #pragma GCC diagnostic or on the command line when compiling. (I should mention that even #pragma GCC diagnostic doesn't work completely reliably with optimization, and I have no idea how or if it works with LTO. It's something I'm yet to look into.)
