[PATCH] Fix inline functions to use 'static inline'

David Woodhouse dwmw2 at infradead.org
Fri Jun 29 08:34:38 UTC 2018

On Thu, 2018-06-28 at 20:29 +0200, Steve Markgraf wrote:
> Hi David,
> On 28.06.2018 17:43, David Woodhouse wrote:
> > 
> > With just 'inline', if the compiler decides not to inline them, it isn't
> > required to emit them at all. For some targets with -Os that is causing
> > build failures.
> "It isn't required to emit them at all" - What the heck, which compiler
> on earth does such horrible things?
> I've taken at look at the C99 standard for the function specifier
> 'inline' and there is nothing that would justify such behaviour.

Yeah, you're probably right. My initial reading of the docs was a
little hasty and mostly based on the assumption (haha) that GCC would
be doing the right thing for something like this, given all the churn
that went on some years ago with static/extern inline handling.

This was seen in the OpenWRT build.

Of course, I question whether we should be building rtl-sdr with -O0 or
-Os and eschewing inlining... that does seem a bit daft for this
*particular* piece of software even if the general policy of the
OpenWRT is to reduce size. But that's a separate discussion, really.
> Of course, if that's a bug with a specific compiler version we can merge
> that, but the explanation in the commit doesn't make any sense to me.


Here's another example FWIW:

 $ cat foo.c

inline int foo(int a)
	return a+1;

int bar(int a)
	return foo(a);
 $ gcc -O0 -o- -S foo.c
	.file	"foo.c"
	.globl	bar
	.type	bar, @function
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	subq	$16, %rsp
	movl	%edi, -4(%rbp)
	movl	-4(%rbp), %eax
	movl	%eax, %edi
	call	foo
	.cfi_def_cfa 7, 8
	.size	bar, .-bar
	.ident	"GCC: (GNU) 8.1.1 20180502 (Red Hat 8.1.1-1)"
	.section	.note.GNU-stack,"", at progbits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180629/b5285105/attachment.bin>

More information about the osmocom-sdr mailing list