[Bug c/39852] New: GCC 4.4.0 builds a broken glibc 2.8

[Bug c/39852] New: GCC 4.4.0 builds a broken glibc 2.8

[sega01 at go-beyond dot org]

Hi,

Sorry for the lack of testing and specificity, but this should be fairly easy
to reproduce. Another user on Freenode's #gcc reported the same problem, so I
don't think it's just my setup. #gcc suggested I use a static gdb for
debugging, but for now I will link to some ltrace and strace dumps.

GCC 4.3.3 (about the latest snapshot, or any version) builds glibc 2.8
(snapshot) just fine, and it seems to be perfectly stable. A few days ago I
wanted to give 4.4.0 a try, so I built GCC, and rebuilt gcc and binutils from
the new GCC. Everything seemed to go fine, so I went on to glibc. glibc built
fine, but after upgrading to it I noticed that most glibc-linked (which is just
about everything on my box) applications segfaulted. Fortunately, strace and
ltrace were seemingly unaffected.

Common patterns I noticed with what broke and what didn't were that Coreutils
stuff broke along with GCC, Bash, nano, sed, vi, but module-init-tools,
Busybox, nsudoku, Pacman, osstest, and time all run just fine (as in no
segfaults).

http://pastebin.com/f21432957 has ltraces and straces of several binaries
linked to glibc that segfault. Let me know if I should do l/straces of binaries
that don't segfault or try something else. This should be quite reproducible
though. Should I try anything else? Sorry for my lack of informedness in this
area, I'll try to learn more when I have the time. This is on Icadyptes, my
Arch Linux fork. I build just about everything with -march=i486 -mtune=generic
-O2 -fomit-frame-pointer -pipe, if it helps. This is on Linux 2.6.28/2.6.29.

[root@silentgnu ~]# gcc -v
Using built-in specs.
Target: i486-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit
--disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu
--disable-libstdcxx-pch --with-tune=generic --host=i486-pc-linux-gnu
--target=i486-pc-linux-gnu --build=i486-pc-linux-gnu
Thread model: posix
gcc version 4.4.0 (GCC)

Thanks,
Teran

PS: Great job on GCC, I was impressed to find that GCC 4.4.0 generally built
smaller binaries than 4.3.3. I didn't get to do any benchmarking, but keep up
the good work :-).


-- 
           Summary: GCC 4.4.0 builds a broken glibc 2.8
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sega01 at go-beyond dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-23 00:09 -------
There is not enough information here.  Do you have a source to a program which
fails with the new glibc compiled with 4.4?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
             Status|UNCONFIRMED                 |WAITING
          Component|c                           |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[sega01 at go-beyond dot org]

------- Comment #2 from sega01 at go-beyond dot org  2009-04-23 00:55 -------
(In reply to comment #1)
> There is not enough information here.  Do you have a source to a program which
> fails with the new glibc compiled with 4.4?
> 

Thank you for the quick response.

The sources for the applications I listed are readily available (I can link to
them directly if need be), but I did find a single readline test source that
segfaults. xz, less, and Lua also segfault. Lua managed to get to a printf
before segfaulting, so I thought it might give a more useful l/strace if
needed. http://tiswww.case.edu/php/chet/readline/rl.c is the readline test
source that segfaults.

Thanks,
Teran

PS: Should I have filled out the bug report differently? Is it acceptable to
change the status back to new after responding?


-- 

sega01 at go-beyond dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2009-04-23 00:57 -------
It might be better if you use gdb instead of using ltrace because those two
programs don't give enough information on what is going on.  This could be
still a bug in Lua or even in glibc itself but without a testcase to figure out
what is going wrong it is hard to debug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[sega01 at go-beyond dot org]

------- Comment #4 from sega01 at go-beyond dot org  2009-04-23 01:10 -------
(In reply to comment #3)
> It might be better if you use gdb instead of using ltrace because those two
> programs don't give enough information on what is going on.  This could be
> still a bug in Lua or even in glibc itself but without a testcase to figure out
> what is going wrong it is hard to debug.
> 

I can give gdb a try, but will let this sit for tonight first. For clarity,
nothing on my system is compiled with GCC 4.4.0 except glibc 2.8 for when I
test. Lua, xz, vi, nano, and all of the programs that segfault only segfault
when I use the GCC 4.4.0 compiled glibc 2.8; if I use glibc 2.8 built with GCC
4.3.3 they run just fine. I don't think this is a bug in any of those programs.
I think this could be a glibc bug, but I'm leaning on GCC since GCC 4.3.3
builds a clean glibc.

Thanks,
Teran


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2009-04-23 06:03 -------
GCC 4.4.0 compiled glibc 2.10 works just fine for me on x86_64, i586, i686,
powerpc and powerpc64.

Anyway, if you say GCC 4.3.3 compiled glibc 2.8 works and 4.4.0 compiled
doesn't, then please do a binary search between 4.3.3 and 4.4.0 compiled
objects to find out on which CU it matters (say configure glibc with CC=gcc
CXX=g++,
then point PATH env var. to wher eyou have gcc 4.4.0 unpacked, build glibc,
verify your testcase breaks, then in the build tree
for i in [a-l]*/*.os; do mv ${i}{,.4.4}; done
change PATH to point to 4.3.3 gcc, make, see whether your testcase breaks or
not and depending on that continue with either half of the [a-l]* or [m-z]*
objects, etc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[sega01 at go-beyond dot org]

------- Comment #6 from sega01 at go-beyond dot org  2009-04-23 20:59 -------
(In reply to comment #5)
> GCC 4.4.0 compiled glibc 2.10 works just fine for me on x86_64, i586, i686,
> powerpc and powerpc64.
> 
> Anyway, if you say GCC 4.3.3 compiled glibc 2.8 works and 4.4.0 compiled
> doesn't, then please do a binary search between 4.3.3 and 4.4.0 compiled
> objects to find out on which CU it matters (say configure glibc with CC=gcc
> CXX=g++,
> then point PATH env var. to wher eyou have gcc 4.4.0 unpacked, build glibc,
> verify your testcase breaks, then in the build tree
> for i in [a-l]*/*.os; do mv ${i}{,.4.4}; done
> change PATH to point to 4.3.3 gcc, make, see whether your testcase breaks or
> not and depending on that continue with either half of the [a-l]* or [m-z]*
> objects, etc.
> 

Thank you for your reply. First few times reading it I didn't notice the first
sentence. I built a static gdb to test with, but also wanted to try glibc 2.9
on GCC 4.4.0. glibc 2.9 was actually smaller than 2.8 compiled with 4.3.3, not
to mention it worked perfectly; so I'm quite happy. I've moved over completely
to GCC 4.4.0 and glibc 2.9 now, and think that this is quite possibly a glibc
2.8 bug. Not sure if this is worth looking into further now, CC'ing a glibc
developer, or what. Sorry about not trying another glibc version earlier,
although it is possible this is still a GCC bug.

Not sure if the status should be changed on bug report, although uncomfirmed
seems about right to me.

Thanks,
Teran


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[thunderwolf66102 at yahoo dot com]

------- Comment #7 from thunderwolf66102 at yahoo dot com  2010-02-01 08:49 -------
Under Gentoo, GCC x86_64-pc-linux-gnu-4.4.2 appears to also build a broken
glibc 2.9.  I have tried many times over the past several days to build and
install gentoo's 2.9_p20081201-r3 to replace a previous 2.9_p20081201-r2. 
After installing the new glibc several binaries would break - among them being
python, squid and init.  Other binaries worked fine.

The first luck I had was I created a fresh environment under a chroot, built
glibc, and copied it over.  Tried to build 2.9_p20081201-r3 and install again
after this with the same problems.  I looked at a couple of other computers
that I have and noticed their default compilers were all set to 4.3.x. 
Switched to 4.3.4 on the problem system, built 2.9_p20081201-r3 and installed
again with no issues.

One of the files related to the segfaults appeared to be libm-2.9.so. 
Replacing this file with the backed up -r2 version restored python.

I believe this has also happened once before though at that point I simply
backed up the system, nuked, and reinstalled.  Python was broken then as well.

flags = -O2 -finline-functions -mtune=athlon64 -march=x86-64
-fomit-frame-pointer -mfpmath=sse,387 -pipe -msse3


-- 

thunderwolf66102 at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thunderwolf66102 at yahoo
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[mikpe at it dot uu dot se]

------- Comment #8 from mikpe at it dot uu dot se  2010-02-01 11:13 -------
There are known aliasing bugs in older glibc releases that result in broken
code when compiled with gcc-4.4. The fix is to update glibc or to patch it. See
<http://gcc.gnu.org/ml/gcc/2009-07/msg00057.html>.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-12-21 21:18:38 UTC ---
Not a gcc bug so closing as such.