gcc44: disable java multilib

[howarth@…]

I am creating this submission for the packaging I placed on #20838 since there were additional problems fixed in the build beyond that specific bug. The packaging has been tested by other users on x86_64-apple-darwin10 but still needs to be tested on i386-apple-darwin*. The changes in the packaging involve...

1. Remove any attempt to 'force' the code generation to m64 because this breaks the multilib build.
2. Add the proposed config.guess patch to eliminate any need to explicitly pass the triplets on x86_64 10.6.
3. Add the patch from PR41180 to avoid the linker bug in darwin10, where static libraries created with 'ranlib -c' don't properly have duplicate symbols ignored, by removing the redundant code from the linkage.
4. Add the RedHat --disable-libjava-multilib to reduce the length and size of the build.
5. Re-enable the multilib build on powerpc-apple-darwin* since the build time will be reasonable now.
6. Add the recommended configure options of...

--with-arch=nocona --with-tune=generic --build=i686-apple-darwin${os.major} --host=i686-apple-darwin${os.major} --target=i686-apple-darwin${os.major}

on i386 darwin* for best performance (as recommended by Mike Stump of Apple compiler group).

[howarth@…]

Portfile to fix gcc44 build and make improvements in builds

[howarth@…]

patch to fix PR41180 that I have already committed to gcc trunk and 4.4 branch

[howarth@…]

patch adding --disable-multilib-libjava that shortens and reduces the build

[ram@…]

Cc Me!

[howarth@…]

FYI, for the gcc45 packaging, we should definitely add a cloog-ppl and ppl package to MacPorts and build gcc 4.5 against those to have access to the graphite code optimizations...

 http://gcc.gnu.org/wiki/Graphite

The loop analysis and optimization methods used by graphite are being significantly extended in gcc 4.5. With any luck, the graphite loop optimization flags will actually yield code improvements in that release (although we are probably talking about 15% or so).

[howarth@…]

I would have thought not having a gfortran compiler available for Snow Leopard would make this a high priority bug, no?

[jschwab@…]

Replying to howarth@…:

I would have thought not having a gfortran compiler available for Snow Leopard would make this a high priority bug, no?

As someone lurking and waiting for a fix, I was hoping it would be. Thanks for the work on a patch.

[thomas.mccullough@…]

Cc Me!

[howarth@…]

update to corrected patch which Mike Stump approves for submission to config-patches

[jschwab@…]

Cc Me!

[ram@…]

Markus, any objections to these changes?

[macsforever2000@…]

Cc Me!

[adfernandes@…]

Cc Me!

[adfernandes@…]

Updated ppl in #26008

[adfernandes@…]

Added port polylib, needed for cloog-ppl, in #26010

[adfernandes@…]

Added port cloog-ppl in #26011

[howarth@…]

Replying to adfernandes@…:

Added port polylib, needed for cloog-ppl, in #26010

Why bother? The ppl package long ago succeeded polylib as the preferred polyhedral library for cloog.

[howarth@…]

Replying to adfernandes@…:

Added port cloog-ppl in #26011

Keep a watch out for any failure of upstream to soversion bump cloog for ppl-0.11.
The gcc compiler loads the ppl headers from the cloog headers. Thus if cloog is rebuilt with
ppl-0.11 without a soversion bump , all gcc packages built against cloog will need rebuilt as well.
Otherwise the ppl data structures used by gcc for cloog calls will be from one ABI (from version 0.10.x)
and the actual cloog routines will be execting ppl data structures based on another ABI (0.11).

[adfernandes@…]

Turns out that cloog checks specifically for ppl version 0.10.x; ppl version 0.11 will not work. I'm adding (testing right now) to add --without-ppl and --without-cloog to gcc45 and gcc46 right now, letting graphite be a variant. (I'll add a ticket when I have them tested.) That *should* keep things mostly independent.

It turns out that gcc45 with ppl and cloog requires a special version of cloog (cloog-ppl from the gnu repository), and that version needs polylib. I tried to build it; that's how I know... :-)

[howarth@…]

Replying to adfernandes@…:

Turns out that cloog checks specifically for ppl version 0.10.x; ppl version 0.11 will not work. I'm adding (testing right now) to add --without-ppl and --without-cloog to gcc45 and gcc46 right now, letting graphite be a variant. (I'll add a ticket when I have them tested.) That *should* keep things mostly independent. It turns out that gcc45 with ppl and cloog requires a special version of cloog (cloog-ppl from the gnu repository), and that version needs polylib. I tried to build it; that's how I know... :-)

Are you passing --with-ppl=/opt/local to configure for the cloog build? On fink, I have always used --with-ppl=%p for our cloog packaging.

[adfernandes@…]

Are you passing --with-ppl=/opt/local to configure for the cloog build? On fink, I have always used --with-ppl=%p for our cloog packaging.

No... I probably should have, but it seems to have built just fine without it. All libraries are linked as they should be. (I'll probably add it now, though.)

I am following the directions archived as follows:

•  http://gcc.gnu.org/install/prerequisites.html
•  http://gcc.gnu.org/wiki/Graphite
•  http://gcc.gnu.org/wiki/Graphite/4.5

gcc4[45] require a special build of cloog, apparently, the latest version of which is cloog-ppl-0.15.9. This library in turn depends on ppl-0.10.x, the latest of which is 0.10.2. I tried 0.11 which was released very recently, and it does not work. The FSF cloog-ppl depends specifically on version 0.10.x.

The old ppl port would not compile because it used an old test for gmp4. I patched configure so that the configure test would work with gmp5.

That being said, In finally have a working graphite-based compiler. :-)

Attached is a patch for gcc4[456]. Some notes:

• I've added a default --without-ppl and --without-cloog to stop gcc from using them without an explicit request.
• I've put the graphite variant as optional.
• I have only tested gcc45 thoroughly with and without the graphite variant. Both work as expected.
• The gcc44 and gcc46 patches should be the same, but I've only configured, not built and tested the compilers.
• ... therefore the diffs don't bump the revision.

Please test!

[adfernandes@…]

patch gcc4[456] to add a graphite variant

[adfernandes@…]

Heh. Silly me. I must have gotten confused with all the dependencies. cloog-ppl uses either ppl or polylib. We need the former. Fixed in r70419.

[howarth@…]

Keep in mind that currently graphite is of little use in gcc 4.5.x. Only in gcc 4.6 are we finally approaching the point where -fgraphite-identity doesn't actually degrade the vectorization achieved...

 http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00159.html

Also currently the higher level graphite optimizations don't achieve any improvements, however once the vectorization loses are eliminated for -fgraphite-identity that option might yield a few percent improvement.

 http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg00666.html vs  http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg00556.html

shows the missed vectorization on using -fgraphite-identity (which converts the gimple to polyhedral represemtations and then back again to gimple (hopefully providing a more accurate representation of the loops than the original gimple).

[adfernandes@…]

Hmm... how interesting. I've been using the equivalent types of optimization within the Intel compilers for a while, and they can really be very beneficial.

Besides - I get too many students not knowing what a "memory stride" is, or getting confused between row-major and column-major storage for me to not want loop reorganization! :-)

I'll just put my faith in the GCC developers and assume that they're playing around with this stuff for good reason.

[adfernandes@…]

Oops, sorry, my fault, I guess. The original point of this ticket was not the graphite optimizations. I'm moving all the graphite-related stuff to #26043. Sorry for the confusion and ticket-scope-creep.

[jmr@…]

So there only seems to be one thing here that's still relevant; changing summary to match. Maybe you could explain why we don't want/need the java multilib?