[PATCH] Inline defn's in stdio.h break gcc bootstrap on cygwin.

[Jeff Johnston]

Dave Korn wrote:
> 
>     Hi Jeff, hope you had a nice break!
> 
>   It's a fairly complicated story, but gcc won't currently bootstrap on
> cygwin.  It's a combination of three factors:
> 
>  - stdio.h uses 'static inline' to declare __sgetc_r (and the
> currently-ifdef'd-out __sputc_r).
>  - gcc uses the -fkeep-inline-functions flag when bootstrapping.
>  - libgcc doesn't link against libcygwin (and in any case should not contain a
> static copy of __sgetc_r in the .ctors section!)
> 
>   For background, you can browse these threads:
> 
> http://cygwin.com/ml/cygwin/2007-03/msg00705.html
> http://gcc.gnu.org/ml/gcc/2007-03/msg00948.html
> http://gcc.gnu.org/ml/gcc/2007-03/msg01088.html
> 
>   The problem basically is that -fkeep-inline-functions causes libgcc to have
> unresolved references to _ungetc et al.  The gcc bootstrap process
> deliberately uses -fkeep-inline-functions to show up problems that would be
> caused by inline functions when bootstrapping gcc with a native (non-gcc)
> compiler, none of which match gcc's functionality of not emitting the body of
> a static inline function unless it has to.  So, the first possibility is to
> switch to using extern inline, which doesn't ever emit the function body, not
> even with -fkeep-inline-functions.  Problem is, the meaning of extern inline
> is shortly changing to be c99-compliant.  So, we end up using a feature test
> to define a macro that means "this function can be omitted if possible".  This
> fixes gcc bootstrap for cygwin.
> 
>   I've tested this to the extent of building winsup and running the cygwin
> testsuite with and without the patch and verifying that it doesn't break the
> build or cause any change in the testsuite results, and verifying that the
> change makes it into the installed stdio.h after "make install".  More testing
> would be good, though.  It's not a neutral change; replacing a static inline
> with an extern inline could I guess cause link errors in some projects.
> Should it perhaps be conditionalised on __CYGWIN32__ or something?  Are there
> maybe some newlib-linux targets that might be affected by this as well?
>

Thanks Dave,

This won't be a problem to anything but Cygwin.  If you notice, the 
inlined functions in question are brought in only when the __SCLE flag 
is set which is done at the top of stdio.h iff __CYGWIN__ is defined.

Now, regarding the patch.  The macro should be _ELIDABLE_INLINE instead 
of ELIDABLE_INLINE to avoid conflicts with the user name-space.  The 
patch should use __inline__ instead of inline in case the user uses the 
-ansi flag.  I might suggest adding to the comment for clarification. 
For example:  "For a platform with CR/LF, additional logic is required 
by __sgetc_r which would otherwise simply be a macro; therefore we use 
an inlined function.  The function is only meant to be inlined in place 
as used and the function body should never be emitted.  There are two 
possible scenarios....explanation of C99 etc...."

Once these things are fixed, the patch is approved.

-- Jeff J.

> 
> 2007-03-28  Dave Korn  <dave.korn@artimi.com>
> 
> 	* libc/include/stdio.h (ELIDABLE_INLINE):  New macro to conceal
> 	conflicting inline semantics between c99 and gnu89.
> 	(__sgetc_r):  Replace static inline with ELIDABLE_INLINE to be
> 	compatible with -fkeep-inline-functions usage.
> 	(__sputc_r):  Likewise for consistency even though disabled.
> 
>     cheers,
>       DaveK