Released today, please bump.
Created attachment 307009 [details] gcc-4.7.0.build gcc-4.7.0.build, modified from latest gcc-4.7.0alpha ebuild (toolchain overlay
There are some new linker plugin wrappers (gcc-{ar,nm,ranlib}) installed into gcc-bin that gcc-config might have to handle. I'm not sure how they work or what their purpose is though.
maybe time for deploying the idea in bug 238984 comment 5 where the eclass populates a variable with all the binaries that gcc version is installing, and then gcc-config just uses that to figure out what to wrap ...
ok, no need for that as i've taken care of it in gcc-config-1.7 Ryan: can you make sure to include these fixes ? they're already in the upstream gcc 4.7 branch. http://lists.uclibc.org/pipermail/uclibc/2012-April/046658.html
Yuuuuuup. The gcc-config changes are working well. Thanks!
So is this ready to roll now?
what's the thinking about building the gcc binaries with gcc vs g++ (the latter's the default for boostrap)? this mostly affects gcc plugins and --disable-build-with-cxx controls it at configure time.
To be honest I skipped that incredibly long thread on gcc-dev. I think we'll follow upstream unless there's a compelling reason not to.
(In reply to comment #8) > To be honest I skipped that incredibly long thread on gcc-dev. I think > we'll follow upstream unless there's a compelling reason not to. It affect #413425 (Hardened-kernel)
Hey, I'll be happy to help get this out the door, if there's something I can do. Having 4.7.0 would help me greatly for some upstream gcc work.
Mike, what's the status of x32 in 4.7? Is it upstream or do we still have to patch it in?
(In reply to comment #11) afaik, it should be in there, so drop it. if there's something more i need, i'll add it after the fact.
08_all_cross-compile.patch will have to be reworked. The MD_UNWIND_SUPPORT macro has been removed and replaced with an auto-generated header. See http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02343.html. It's probably just a case of figuring out where to move the inhibit_libc check. The move of libgcc to toplevel means many of our patches don't apply. I'm about halfway through them and hope to have this in the tree in the next couple days.
it can be dropped. crossdev switched to --with-headers a long time ago making that unnecessary. if i feel like resurrecting it, i'll do so after 4.7.0 is added to the tree, but i most likely won't bother.
i've queued that change to the 4.6.x and 4.7.x patchsets
This is ready to go. I'll push it out tomorrow.
Bumped. Thanks everyone. I'm sorry about the wait.
(In reply to comment #17) > Bumped. Thanks everyone. I'm sorry about the wait. Thanks for continuing to work on it :-) A quick question: is current policy about LTO still the same with 4.7? (Meaning, use at your own risk and don't report bugs about it?)
It says as much right when you emerge it. :)
Would I be correct to assume that lto problems should still be considered reportable directly to upstream?
Yes but you may want to test a self-compiled vanilla version to make sure the bug is reproducible by upstream.
New caveat found on gcc.gnu.org: "GCC versions 4.7.0 and 4.7.1 had changes to the C++ standard library which affected the ABI in C++11 mode: a data member was added to std::list changing its size and altering the definitions of some member functions, and std::pair's move constructor was non-trivial which altered the calling convention for functions with std::pair arguments or return types. The ABI incompatibilities have been fixed for GCC version 4.7.2 but as a result C++11 code compiled with GCC 4.7.0 or 4.7.1 may be incompatible with C++11 code compiled with different GCC versions and with C++98/C++03 code compiled with any version."
Okay let's stop replying to this bug now.
