On 25 March 2007 07:37, Andrew Pinski wrote: > On 3/24/07, Brian Dessent <[EMAIL PROTECTED]> wrote: >> Dave Korn wrote: >> >>> # 405 "/usr/include/stdio.h" 3 4 >> >> [ Which is from newlib (libc/include/stdio.h) if anyone reading this >> doesn't have a Cygwin system handy. ] >> >>> static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p) { >>> [...] >>> >>> The critical difference is the presence or absence of >>> -fkeep-inline-functions. I think I remember there being some change >>> between gcc-3.x and gcc-4.x in inline handling and I think that's what's >>> biting us now; I think this may only arise in stage1 where we're trying >>> to use 3.x to compile 4.x. >> >> I too thought that this was related to the c99 inline changes, but I >> think those only apply to "extern inline" which is not the case here. >> >> The real cause seems to be that -fkeep-inline-functions was a no-op up >> until: <http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01396.html>, which >> seems to roughly correspond to when bootstrap stopped working on Cygwin. >> > > Actually it was not a no-op in 3.4, just 4.2 (or was it also broken in > 4.1) broke -fkeep-inline-functions and nobody noticed until later. > Cygwin's headers are broken with respect of -fkeep-inline-functions > and need to be fixed.
This is the conclusion I came to. We certainly don't want to emit those functions in libgcc's _ctors.o. Eric Bocatzou added -fkeep-inline-functions while fixing PR18058 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058) for I assume was the specific purpose of making these kinds of problems show up sooner rather than later. On 25 March 2007 07:33, Brian Dessent wrote: > So it looks like we need to either stop using -fkeep-inline-functions > for this file, change the definition to extern inline (or extern inline > plus __attribute__((gnu_inline))? I'm still a little confused there), > or link against -lcygwin. I kind of think the latter sounds wrong, > since there really is no reason that these unused function bodies should > end up in the .o file simply because it happens to have #include > <stdio.h> at the top. Yeh, I'm a little confused too... or do we have to define a macro that gets set to "static inline" or "extern inline" according to GNUC_xxx version tests? cheers, DaveK -- Can't think of a witty .sigline today....