Bug #4123
closedgcc & LTO related issues
0%
Description
The new and shiny gcc 9.x will happily do cross-TU analysis, and LTO allows discovering hidden "issues", i.e. FSMs that could in theory access unitialized data. This is not really helpful, but our own compilation flags kill the builds completely:
grep -riIl "error=null" | grep \.ac$ | xargs grep null-deref osmo-bsc/configure.ac:AX_CHECK_COMPILE_FLAG([-Werror=null-dereference], [CFLAGS="$CFLAGS -Werror=null-dereference"]) osmo-sgsn/configure.ac:AX_CHECK_COMPILE_FLAG([-Werror=null-dereference], [CFLAGS="$CFLAGS -Werror=null-dereference"]) osmo-msc/configure.ac:AX_CHECK_COMPILE_FLAG([-Werror=null-dereference], [CFLAGS="$CFLAGS -Werror=null-dereference"]) osmo-mgw/configure.ac:AX_CHECK_COMPILE_FLAG([-Werror=null-dereference], [CFLAGS="$CFLAGS -Werror=null-dereference"])
As evident by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 there is no way to influence warnings and errors by using pragmas, which is not entirely unexpected due to the way LTO works.
There is also no other way to tell the compiler not to warn, we can only prove the non-nullness by throwing obvious wrenches into the code, like if(!x) exit(); which would at most please the compilerbeast while providing no additional benefits.
And there is the minor issue that Werror will even turn messages like "error: potential null pointer dereference [-Werror=null-dereference]" into errors, where gcc doesn't even know if there is an issue. Breaking the build due warnings that involve the word "potential" is bad idea.
Additionally LTO breaks -Wl,-wrap, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 - this might get fixed, but it breaks all tests that are using this feature.
Related issues