[Bug build/20729] glibc-2.24 fails to build for i486 with -Os

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20729

--- Comment #20 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to joseph@codesourcery.com from comment #19)
> On Fri, 28 Oct 2016, carlos at redhat dot com wrote:
> 
> > FAIL: conform/ISO/assert.h/linknamespace
> > FAIL: conform/ISO/locale.h/linknamespace
> 
> The list of headers isn't really interesting here; it's the contents of 
> the test output files.  Presumably there are a few key functions that get 
> inlined for -O2 but not -Os and are responsible for a large proportion of 
> these failures because some code using them gets pulled in for most/all 
> static links.  Fixes would need determining case-by-case, e.g. making a 
> function always_inline, making a header inline visible for -Os when 
> building glibc, or using an internal-namespace name for a function while 
> making sure that gets inlined for -O2 just as the user-namespace version 
> got inlined.  (But the linknamespace failures are bug 19463 and localplt 
> failures with -Os are bug 15105, so this bug should be considered to be 
> just about the build failure, and separate bugs filed for other defects in 
> the resulting libc that don't already have their own bugs.)

Right, it's these extra PLT references which show which functions are not
getting inlined and thus cause the major problems. For example feof_unlocked is
a serious offender in a lot of the linknamespace failures.

I agree that this bug should just cover the build failures.

So we have two things to work out:

* Issues with -fomit-frame-pointer, fixed by Florian's patch.
* Issues with -Werror, fixed by my patch under discussion.

I think Florian's patch can go in right now though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.