* libc/include/stdio.h (_ELIDABLE_INLINE): Move definition from here...

	* libc/include/_ansi.h (_ELIDABLE_INLINE): ..to here.

1 files changed, 1 insertions, 22 deletions

diff --git a/newlib/libc/include/stdio.h b/newlib/libc/include/stdio.h
index e5aac375e..6db5151ca 100644
--- a/newlib/libc/include/stdio.h
+++ b/newlib/libc/include/stdio.h
@@ -589,28 +589,7 @@ FILE *_EXFUN(_fopencookie_r,(struct _reent *, void *__cookie,
   There are two possible means to this end when compiling with GCC,
   one when compiling with a standard C99 compiler, and for other
   compilers we're just stuck.  At the moment, this issue only
-  affects the Cygwin target, so we'll most likely be using GCC.
-
-  The traditional meaning of 'extern inline' for GCC is not
-  to emit the function body unless the address is explicitly
-  taken.  However this behaviour is changing to match the C99
-  standard, which uses 'extern inline' to indicate that the
-  function body *must* be emitted.  If we are using GCC, but do
-  not have the new behaviour, we need to use extern inline; if
-  we are using a new GCC with the C99-compatible behaviour, or
-  a non-GCC compiler (which we will have to hope is C99, since
-  there is no other way to achieve the effect of omitting the
-  function if it isn't referenced) we just use plain 'inline',
-  which c99 defines to mean more-or-less the same as the Gnu C
-  'extern inline'.  */
-#if defined(__GNUC__) && !defined(__GNUC_STDC_INLINE__)
-/* We're using GCC, but without the new C99-compatible behaviour.  */
-#define _ELIDABLE_INLINE extern __inline__ _ATTRIBUTE ((__always_inline__))
-#else
-/* We're using GCC in C99 mode, or an unknown compiler which 
-  we just have to hope obeys the C99 semantics of inline.  */
-#define _ELIDABLE_INLINE __inline__
-#endif
+  affects the Cygwin target, so we'll most likely be using GCC. */
 
 _ELIDABLE_INLINE int __sgetc_r(struct _reent *__ptr, FILE *__p);