public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/17266] Always defining __extern_always_inline may generate infinite recursion Date: Tue, 16 Sep 2014 08:41:00 -0000 [thread overview] Message-ID: <bug-17266-131-MO2JsIC8dA@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-17266-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=17266 --- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via 884ddc5081278f488ef8cd49951f41cfdbb480ce (commit) from a7b872687073decdcc7effc2289877d69058aca9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=884ddc5081278f488ef8cd49951f41cfdbb480ce commit 884ddc5081278f488ef8cd49951f41cfdbb480ce Author: Siddhesh Poyarekar <siddhesh@redhat.com> Date: Tue Sep 16 14:08:48 2014 +0530 Revert to defining __extern_inline only for gcc-4.3+ (BZ #17266) The check for only __GNUC_STDC_INLINE__ and __GNUC_GNU_INLINE__ may not be sufficient since those flags were added during initial support for C99 inlining semantics. There is also a problem with always defining __extern_inline and __extern_always_inline, since it enables inline wrapper functions even when GNU inlining semantics are not guaranteed. This, along with the possibility of such wrappers using redirection (btowc for example) could result in compiler generating an infinitely recusrive call to the function. In fact it was such a recursion that led to this code being written the way it was; see: https://bugzilla.redhat.com/show_bug.cgi?id=186410 The initial change was to fix bugs 14530 and 13741, but they can be resolved by checking if __fortify_function and/or __extern_always_inline are defined, as it has been done in this patch. In addition, I have audited uses of __extern_always_inline to make sure that none of the uses result in compilation errors. There is however a regression in this patch for llvm, since it reverts the llvm expectation that __GNUC_STDC_INLINE__ or __GNUC_GNU_INLINE__ definition imply proper extern inline semantics. 2014-09-16 Siddhesh Poyarekar <siddhesh@redhat.com> Jakub Jelinek <jakub@redhat.com> [BZ #17266] * libio/stdio.h: Check definition of __fortify_function instead of __extern_always_inline to include bits/stdio2.h. * math/bits/math-finite.h [__USE_XOPEN || __USE_ISOC99]: Also check if __extern_always_inline is defined. [__USE_MISC || __USE_XOPEN]: Likewise. [__USE_ISOC99] Likewise. * misc/sys/cdefs.h (__fortify_function): Define only if __extern_always_inline is defined. [!__cplusplus || __GNUC_PREREQ (4,3)]: Revert to defining __extern_always_inline and __extern_inline only for g++-4.3 and newer or a compatible gcc. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 16 ++++++++++++++++ libio/stdio.h | 2 +- math/bits/math-finite.h | 8 +++++--- misc/sys/cdefs.h | 21 +++++++++++---------- 4 files changed, 33 insertions(+), 14 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2014-09-16 8:41 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-08-14 0:34 [Bug libc/17266] New: " siddhesh at redhat dot com 2014-08-14 11:45 ` [Bug libc/17266] " jakub at redhat dot com 2014-08-14 16:45 ` schwab@linux-m68k.org 2014-08-14 16:50 ` jakub at redhat dot com 2014-09-16 8:41 ` cvs-commit at gcc dot gnu.org [this message] 2014-09-16 8:46 ` cvs-commit at gcc dot gnu.org 2014-09-16 8:47 ` siddhesh at redhat dot com 2014-09-16 16:56 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-17266-131-MO2JsIC8dA@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).