Incorporation of GCC 4.7

[korli]

Provisioning ticket for GCC 4.7 to track activities and see if it works well.

[jprostko]

I pretty much have GCC 4.7.2 patched to work with Haiku. This patch which I will attach soon will definitely change before final, as I am hoping to backport a fix that will likely go into GCC trunk soon. Depending on timing, that change could potentially make it into GCC 4.7.3, actually.

Here is a link to part of that discussion regarding the fix for handling the JCR section better. ​http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00954.html

I have addressed it another way locally to keep things brief, but if the above mentioned fix makes it into GCC mainline in one form or another, I will make our patch match accordingly.

Other than that, I also need to likely strip out target-libiberty from noconfigdirs of the toplevel GCC configure, as I believe it was deprecated and serves no purpose now. I want to do thorough testing to confirm that though.

After attaching the patch, I will mention known current issues that I am seeing.

[jprostko]

Initial GCC 4.7.2 patch, which will almost definitely change somewhat

[jprostko]

Known issue 1:

During a cross-compile, GCC will fail due to a "No link tests allowed after GCC_NO_EXECUTABLES". Basically, due to updated Libtool definitions, GCC expects us to provide system libraries/objects as part of the build. This includes libroot.so, crti.o, start_dyn.o, init_term_dyn.o, and crtn.o.

I see three ways to solve this:

1.) Provide these files for every known variant of Haiku within the Haiku source code, and copy them over while doing the crosstools build. I don't see this as being a sustainable solution though, seeing as we are ultimately targetting a lot of additional platforms like ARM/Mipsel/PPC, as well as their variants. These files would need to be updated from time to time also if anything fundamentally changed with respect to them.

2.) Build a simple GCC compiler first, which can then build those files we need, which can then be used to build the full-blown cross-compiler. I don't really see this as doable either, as compile times for the buildtools will be extremely long, even with us only building the GCC prerequisites (GMP/MPFR/MPC) once by moving them outside of the GCC source tree.

3.) For a cross-build only, reuse what we did in GCC 4.6.3, and have something like is seen here: ​http://cgit.haiku-os.org/buildtools/tree/gcc/libstdc++-v3/configure#n11193 . This hardcodes how things work for Haiku, instead of testing for them instead, which allows the build to go along happily. While this works, it still doesn't feel like the "right" way to go about solving the problem, and it wouldn't be something we'd ever upstream.

If anybody can think of an elegant/simple solution to this, I'm all ears. Right now I'm inclined to go with #3 due to it not adding a lot of complexity to things. Again, we'd only have it affect the cross-build, not a native build of GCC.

[jprostko]

Known issue 2:

While including -Wno-narrowing to build/jam/BuildSetup and building Haiku, Haiku boots up to a system with no text anywhere at all. Even with rebuilding Freetype and ICU with a natively built GCC 4.7.2 and replacing them, Haiku still boots up with no text. I'm not sure if this is the result of a narrowing conversion being disabled, or if it is just the result of something being compiled differently with GCC 4.7.2.

As a TODO, the narrowing conversion issues should be fixed in Haiku code, and -Wno-narrowing should not be added at all to BuildSetup (unless we see false positives). I was doing that initially though to speed up my testing, as the narrowing conversion issue happens at least in two files, and likely many more in the Haiku source.

That said, the issue that results in no text could lie deeper and have nothing at all to do with the way narrowing conversion is handled.

Below I will attach a file with errors seen in two files with narrowing conversion issues. I admit my confidence in touching code like this isn't too high, so if anybody else wants to jump on these, feel free. Just know that likely more files have issues. Also, I probably generated these errors several weeks ago, so the line numbers mentioned could be wrong if these files have changed in the meantime.

[jprostko]

Files showing problems with GCC's Narrowing Conversion

[jprostko]

Known issue 3:

After the x86_64 merge, Haiku will not compile all that far with GCC 4.7.2 for an x86 build. I get the following error post-hrev44541 (I think, as I'm away from my notes until Sunday):

C++ /home/jprostko/haiku-exp/haiku/generated-gcc4/objects/haiku/x86/release/system/kernel/arch/x86/apm.o
/home/jprostko/haiku-exp/haiku/src/system/kernel/arch/x86/32/apm.cpp:
In function 'status_t apm_init(kernel_args*)':
/home/jprostko/haiku-exp/haiku/src/system/kernel/arch/x86/32/apm.cpp:277:39:
error: cannot bind packed field
'args->kernel_args::platform_args.platform_kernel_args::apm' to
'apm_info&'

I'm not sure why GCC 4.6.3 chugs along happily, but GCC 4.7.2 complains. I'm not sure if one struct is declared packed and another one isn't? I admit I got distracted from investigating this, as I was trying to find some good way to handle the cross-compiler situation in "Known issue 1".

There may be more issues to uncover, as I have only been doing my testing so far building x86 buildtools for the most part. As such, I want to test at least x86_64 as well, to make sure everything builds fine, and to perhaps uncover any other issues.

[korli]

The narrowing conversion and "cannot bind packed field" issues should be fixed in hrev45558. The option "-nostart" has been replaced by its synonym "-shared" in hrev45551.

Here too, Haiku boots up to a system with no text anywhere at all when built with GCC 4.7 :/

[korli]

The "no text" behavior is fixed with a workaround in hrev45576. I'll try to come up with a smaller testcase.

Works also nicely with x86_64. Failed to build the ARM cross compiler so far.

[mt]

Hi, there seems to be some more narrowing conversion warnings. please see patch.

[korli]

Thanks applied partially, I hope it's OK in hrev45608.

[mt]

Hi, GCC 4.8 reports more narrowing conversion warnings.

[korli]

Thanks applied partially in hrev45666.

[korli]

4.7.3 integrated in btrev43056. GCC with graphite fixed in btrev43057. ppc and m68k builds fixed in btrev43058.