https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91988
Bug ID: 91988
Summary: Inlining fails with LTO enabled
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at tobias dot goedderz.info
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Inlining fails with LTO when there is an argument with a destructor. This seems
unintentional to me, given the following behaviour.
Given the following example files:
==> main.cpp <==
#include "lib.h"
int main() {
return fun(A{});
}
==> lib.h <==
#ifndef LIB_H
#define LIB_H
class A { public: ~A() {} };
__attribute__((always_inline))
int fun(A);
#endif // LIB_H
==> lib.cpp <==
#include "lib.h"
__attribute__((always_inline))
int fun(A a) { return 0; }
and compiling with
/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -c lib.cpp
/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -c main.cpp
/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -o main-gcc main.o lib.o
fails with
error: inlining failed in call to always_inline ‘fun(A)’: mismatched
arguments
in the last step.
Removing "__attribute__((always_inline))" and inspecting the deassembled output
confirms that the function isn't inlined.
If the body is moved to the header file (and the "inline" specifier added), the
function is inlined.
If the destructor of "A" is removed, or changed to "~A() = default", the
function is inlined.
If the argument to "fun" is changed to a "const&", the function is inlined.
