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

[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.

[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

[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

[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

[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 #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

[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 #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 #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