RE: -fkeep-inline-functions and broken Cygwin bootstrap (was: Building GCC 4.3.0 on Cygwin...)

["Dave Korn" <dave dot korn at artimi dot com>]

On 25 March 2007 07:37, Andrew Pinski wrote:

> On 3/24/07, Brian Dessent <brian@dessent.net> 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....