Using -flto exposes some new warnings in code, as seen in the both build logs below, for upstream elfutils and systemd. I have seen others. These upstreams enable -Werror by default, but probably don't see these warnings turning to errors themself, because the LTO flags are usually injected by the packaging tools.
e.g. https://launchpadlibrarian.net/536740411/buildlog_ubuntu-hirsute-ppc64el.systemd_248.666.gd4d7127d94+21.04.20210503043716_BUILDING.txt.gz e.g. https://launchpadlibrarian.net/536683989/buildlog_ubuntu-hirsute-amd64.elfutils_0.183.43.g92980edc+21.04.20210502190301_BUILDING.txt.gz showing: ../src/shared/efi-loader.c: In function ‘efi_get_reboot_to_firmware’: ../src/shared/efi-loader.c:168:16: error: ‘b’ may be used uninitialized in this function [-Werror=maybe-uninitialized] i386_lex.c: In function ‘i386_restart’: i386_lex.c:1816:25: error: potential null pointer dereference [-Werror=null-dereference] 1816 | b->yy_bs_column = 0; A coworker worked out by review that these warnings are false positives. Now the first option already has the *maybe* in it's name, the second option gives this hint in the message (*potentially*). Now getting the complaint that -Werror isn't usable with -flto anymore. Would it make sense to mark warnings with a high potential of false positives, which are not turned into errors with -Werror? And only turn these into errors with a new option, e.g. -Wall-errors? Matthias
