Project

General

Profile

Actions

Bug #4123

closed

gcc & LTO related issues

Added by Hoernchen over 4 years ago. Updated about 4 years ago.

Status:
Rejected
Priority:
Low
Assignee:
Target version:
-
Start date:
07/19/2019
Due date:
% Done:

0%

Spec Reference:

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

Related to OsmoSGSN - Bug #4116: osmo-sgsn fails to compile on openSUSE Tumbleweed (gcc 9.1 with LTO enabled)ResolvedHoernchen07/17/2019

Actions
Related to OsmoMSC - Bug #4115: osmo-msc fails to compile on openSUSE Tumbleweed (gcc 9.1 with LTO enabled)ResolvedHoernchen07/17/2019

Actions
Related to OsmoGGSN (former OpenGGSN) - Bug #4114: osmo-ggsn fails to compile on openSUSE Tumbleweed (gcc 9.1 with LTO enabled)ResolvedHoernchen07/17/2019

Actions
Related to OsmoBSC - Bug #4113: osmo-bsc fails to compile on openSUSE Tumbleweed (gcc 9.1 with LTO enabled)ResolvedHoernchen07/17/2019

Actions
Related to OpenBSC - Bug #4112: OpenBSC fails to compile on openSUSE Tumbleweed (gcc 9.1 with LTO enabled)ResolvedHoernchen07/17/2019

Actions
Actions #1

Updated by Hoernchen over 4 years ago

  • Assignee set to Hoernchen
Actions #2

Updated by Hoernchen over 4 years ago

  • Related to Bug #4116: osmo-sgsn fails to compile on openSUSE Tumbleweed (gcc 9.1 with LTO enabled) added
Actions #3

Updated by Hoernchen over 4 years ago

  • Related to Bug #4115: osmo-msc fails to compile on openSUSE Tumbleweed (gcc 9.1 with LTO enabled) added
Actions #4

Updated by Hoernchen over 4 years ago

  • Related to Bug #4114: osmo-ggsn fails to compile on openSUSE Tumbleweed (gcc 9.1 with LTO enabled) added
Actions #5

Updated by Hoernchen over 4 years ago

  • Related to Bug #4113: osmo-bsc fails to compile on openSUSE Tumbleweed (gcc 9.1 with LTO enabled) added
Actions #6

Updated by Hoernchen over 4 years ago

  • Related to Bug #4112: OpenBSC fails to compile on openSUSE Tumbleweed (gcc 9.1 with LTO enabled) added
Actions #7

Updated by Hoernchen over 4 years ago

  • Status changed from New to Stalled
Actions #8

Updated by laforge over 4 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?

Actions #9

Updated by Hoernchen over 4 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.

Actions #11

Updated by laforge about 4 years ago

  • Status changed from Stalled to Rejected
  • Priority changed from Normal to Low
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)