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.