This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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:

  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 <>

	* 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]