Bug 783979

OT, gcc currently doesn't seem to rebuild either, while I've fixed a profiledbootstrap failure, now there seems to be buggy (possibly miscompiled, who knows) doxygen, at least http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=361424
looked (until I've cancelled it) like stuck doing doxygen forever.
And the baseurl=http://ppc.koji.fedoraproject.org/mash/rawhide/ppc64/os/
mock doesn't like to rebuild gcc either, yum complains about missing /usr/share/java/eclipse-ecj.jar.

the older gcc builds just fine and even doxygen had no problems at all.
It looks like there's an issue with the new gcc as doxygen loops while looking for input files, p.e.
lstat64("include", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getcwd("/builddir/build/BUILD/gcc-4.7.0-20120123/obj-ppc64-redhat-linux/ppc64-redhat-linux/libstdc++-v3", 4096) = 96
access("/builddir/build/BUILD/gcc-4.7.0-20120123/obj-ppc64-redhat-linux/ppc64-redhat-linux/libstdc++-v3/include/stdalign.h", F_OK) = -1 ENOENT (No such file or directory)
access("include", F_OK)                 = 0
lstat64("include", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getcwd("/builddir/build/BUILD/gcc-4.7.0-20120123/obj-ppc64-redhat-linux/ppc64-redhat-linux/libstdc++-v3", 4096) = 96
access("/builddir/build/BUILD/gcc-4.7.0-20120123/obj-ppc64-redhat-linux/ppc64-redhat-linux/libstdc++-v3/include/stdalign.h", F_OK) = -1 ENOENT (No such file or directory)

This repeats again and again until it gets killed. There are no header files in that directory so there are two bugs: doxygen should handle that more gracefully and gcc needs to put the files where it tells doxygen to look for them,

But the same src.rpm built just fine on all other arches.  Anyway, I see that gcc-4.7.0-0.9.fc17 built, did you need to tweak it in any way?

I've updated the repository at http://ppc.koji.fedoraproject.org/mash/rawhide/ppc64/os/, please try again with yum.

I've tried to build the latest glibc again on my power7 now that you've built gcc-4.7.0-0.10.fc17, but glibc-2.15-1 still fails with the same error.

I'm looking into it.

-fno-inline-functions is no longer enough to prevent gcc from inlining call_gmon_start into _init while compiling sysdeps/generic/initfini.c.  The inlined function has a branch to the end, but the branch is in the PROLOG portion whereas the label ends up in the EPILOG portion, and each portion is assembled separately.

We need -fno-inline-functions-called-once (a new flag) to get the intended behavior.  Arguably, -fno-inline-functions should imply -fno-inline-functions-called-once, but that's not what it does ATM.

Couldn't we add a noinline attribute to call_gmon_start?  Just looking at other alternatives...

I'd think so, but perhaps for the future GCCs you need noclone attribute too in case some GCC version decides to clone it.

s/-fno-inline-functions/-fno-inline/ in initfini build rules is the solution glibc is going with, patch pending.  IBM had run into this and worked around it by adding -fno-inline to CFLAGS-initfini.s in sysdeps/powerpc/powerpc64/Makefile

http://sourceware.org/ml/libc-alpha/2012-01/msg00195.html has the work-around patch.

Thanks Alex (& Ryan).  I've installed the change into rawhide, so the next round of PPC builds will hopefully run without a hitch.  Obviously if Uli checks in something different upstream I'll update the Fedora patch appropriately.

I don't think there was acknowledgement to my solution (patch).  Alexandre, if
you feel that my patch solves the particular problem at hand then please
comment on the ml.  I'll then resubmit to libc-alpha to make sure it's the
desired solution. In the bug I created the patch for we were seeing init
branching directly to fini due to aggressive inlining.