This is the mail archive of the
mailing list for the newlib project.
Re: [PATCH] Inline defn's in stdio.h break gcc bootstrap on cygwin.
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: Dave Korn <dave dot korn at artimi dot com>
- Cc: newlib at sources dot redhat dot com
- Date: Thu, 29 Mar 2007 12:03:49 -0400
- Subject: Re: [PATCH] Inline defn's in stdio.h break gcc bootstrap on cygwin.
- References: <008a01c77191$c3bbf460$2e08a8c0@CAM.ARTIMI.COM>
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
- 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?
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 <firstname.lastname@example.org>
* 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.