On Thursday, April 2, 2020 1:00:31 PM CEST Martin Liška wrote:

On 4/2/20 11:52 AM, Stefan Brüns wrote:

...

On Donnerstag, 2. April 2020 09:33:06 CEST Martin Liška wrote:

...

On 4/2/20 12:34 AM, Aaron Puchert wrote:

...

Am 01.04.20 um 20:14 schrieb Stefan Brüns:

...

On Mittwoch, 1. April 2020 19:44:04 CEST Jason Craig wrote:

...

The reason for that being that store() is defined "inline" in binarystoragebuffer.c. Inline means to replace the function call with the body of the function wherever it is called. This means you need to have the body of the function in the header file (binarystoragebuffer.h), not a source file. By the time the source file is compiled and linking is happening, it is too late to inline a function.

So I'd guess that in the other versions gcc has ignored the inline and treated it as a normal function, whereas the Tumbleweed x86_64 has honored the inline and dropped the function from the object file.

To fix it, the simplest way is to remove "inline" from the function definition. You could also move the inline definition to the header file, but as demonstrated this function is fairly unlikely to actually be inlined by the compiler.

This seems to be a regression, as it deviates from GCCs own documentation: https://gcc.gnu.org/onlinedocs/gcc/Inline.html

I thought so too, but looking at the standard seems to indicate that GCC

is allowed to do this (http://eel.is/c++draft/dcl.inline#5): If a function or variable with external or module linkage is declared inline in one definition domain, an inline declaration of it shall be reachable from the end of every definition domain in which it is declared; no diagnostic is required.

"Definition domain" is what used to be a "translation unit", the latest published draft [1] still uses that term.

Of course GCC can provide guarantees beyond the requirements of the standard, if the developers want to, since "no diagnostic is required."

Hello.

I can only confirm what Aaron says. More details can be seen here: https://gcc.gnu.org/onlinedocs/gcc/Inline.html

"" When an inline function is not static, then the compiler must assume that there may be calls from other source files; since a global symbol can be defined only once in any program, the function must not be defined in the other source files, so the calls therein cannot be integrated. Therefore, a non-static inline function is always compiled on its own in the usual fashion. ""

In a single translation unit, the compiler is free to inline some instances of a function, and keep some invocations as function calls, correct?

Yes.

...

So what contradicts keeping exactly *one* definition (in this case in binarystoragebuffer.cpp) with external linkage?

How do you want to achieve that without a knowledge where else will be a header files included for other compilation units? A compiler works on CU-level (without LTO).

Because the header file does not have a definition, just the the declaration? The declaration has no "inline", so the compiler can and must assume it has the only definition, and it must emit a global symbol. It is the same as if the definition had no "inline" keyword. The compiler should mostly behave if neither declaration nor definition had the "inline" keyword, just taking it as a hint to inline in the current CU. If the other CUs had a definition, this would be a violation of the ODR. But this is always the case, no matter if inline or not. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019