gcc & LTO related issues
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.
Updated by laforge almost 3 years ago
so what is the recommended course of action here? Given that you investigated the issue, I'm wondering what we should do now. Disable "Werror=null-dereference" for normal builds and [if at all] enable it only for our jenkins build verification?
Updated by Hoernchen almost 3 years ago
This can't be fixed on our side, at least not the breaking of wrapping, and if someone feels like chasing down errors for a few days without reasonable context due to inlining it should be revisited in a year or so. Until then the only fix is to disable LTO, or rather: to not force LTO upon unsuspecting packages by third parties.