[Bug libc/17266] New: Always defining __extern_always_inline may generate infinite recursion

["siddhesh at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17266

            Bug ID: 17266
           Summary: Always defining __extern_always_inline may generate
                    infinite recursion
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: siddhesh at redhat dot com
          Reporter: siddhesh at redhat dot com
                CC: drepper.fsp at gmail dot com

The fix for bug 14530 and bug 13741 cause a regression that may cause older
compilers to generate infinite recursion for wrapper functions that rely on GNU
extern inline semantics of newer compiler versions, i.e. g++4.3 and later.

Consider say:

#include <wchar.h>

volatile int i = ' ';
wint_t (*fn) (int) = btowc;

int
main ()
{
  asm ("");
  i = fn (i);
  return 0;
}

When this is compiled e.g. with g++ 3.2, because of the incorrect
BZ #14530, #13741 fix, the program will recurse endlessly.
That is because g++ < 4.3 only provided the C++ inline semantics, not
gnu_inline, but when glibc headers use __extern_inline,
__extern_always_inline or __fortify_function, they rely on GNU extern inline
semantics.  The C++ inline semantics when btowc can't be inlined is
that the compiler emits a comdat out of line, but btowc is:
extern wint_t __btowc_alias (int __c) __asm ("btowc");

__extern_inline wint_t
__NTH (btowc (int __c))
{ return (__builtin_constant_p (__c) && __c >= '\0' && __c <= '\x7f'
          ? (wint_t) __c : __btowc_alias (__c)); }

When the compiler emits out of line copy of this, it will be e.g. on
i?86/x86_64 .globl btowc; btowc: jmp btowc;
Similarly with any other __extern_*inline functions in glibc headers that
sometimes call the original function through aliases.
One can get the problematic definitions out of line even with
-fkeep-inline-functions and similar.

The code before these fixes was the most reliable way to handle this, so the
above bugs ought to be fixed in a different manner.

-- 
You are receiving this mail because:
You are on the CC list for the bug.