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

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

3 files changed, 27 insertions, 22 deletions

diff --git a/newlib/ChangeLog b/newlib/ChangeLog
index 10cccb5..2b72785 100644
--- a/newlib/ChangeLog
+++ b/newlib/ChangeLog
@@ -1,3 +1,8 @@
+2009-04-04  Corinna Vinschen  <corinna@vinschen.de>
+
+	* libc/include/stdio.h (_ELIDABLE_INLINE): Move definition from here...
+	* libc/include/_ansi.h (_ELIDABLE_INLINE): ..to here.
+
 2009-04-03  Yaakov Selkowitz  <yselkowitz@users.sourceforge.net>
 
 	* libc/include/stdio.h [__SCLE] (__sgetc_r): Prototype before define
diff --git a/newlib/libc/include/_ansi.h b/newlib/libc/include/_ansi.h
index a3f0334..3ece8e1 100644
--- a/newlib/libc/include/_ansi.h
+++ b/newlib/libc/include/_ansi.h
@@ -79,6 +79,27 @@
 #define _ATTRIBUTE(attrs)
 #endif
 
+/*  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
+
 /*  ISO C++.  */
 
 #ifdef __cplusplus
diff --git a/newlib/libc/include/stdio.h b/newlib/libc/include/stdio.h
index e5aac37..6db5151 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);