Opened 15 years ago

Last modified 7 years ago

#21341 assigned enhancement

gcc44: disable java multilib

Reported by: howarth@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.8.0
Keywords: Cc: tommccullough-tenica, jschwab@…, adfernandes (Andrew Fernandes)
Port: gcc44

Description (last modified by mf2k (Frank Schima))

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

Attachments (5)

Portfile_optimized.diff (2.7 KB) - added by howarth@… 15 years ago.
Portfile to fix gcc44 build and make improvements in builds
gcc44-PR41180.diff (632 bytes) - added by howarth@… 15 years ago.
patch to fix PR41180 that I have already committed to gcc trunk and 4.4 branch
gcc44-disable-libjava.diff (1.6 KB) - added by howarth@… 15 years ago.
patch adding --disable-multilib-libjava that shortens and reduces the build
gcc44-config.guess.diff (1.1 KB) - added by howarth@… 15 years ago.
update to corrected patch which Mike Stump approves for submission to config-patches
gcc-graphite.diff (2.9 KB) - added by adfernandes (Andrew Fernandes) 14 years ago.
patch gcc4[456] to add a graphite variant

Download all attachments as: .zip

Change History (31)

Changed 15 years ago by howarth@…

Attachment: Portfile_optimized.diff added

Portfile to fix gcc44 build and make improvements in builds

Changed 15 years ago by howarth@…

Attachment: gcc44-PR41180.diff added

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

Changed 15 years ago by howarth@…

Attachment: gcc44-disable-libjava.diff added

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

comment:1 Changed 15 years ago by skymoo (Adam Mercer)

Cc: ram@… added

Cc Me!

comment:2 Changed 15 years ago by 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).

comment:3 Changed 15 years ago by mf2k (Frank Schima)

Description: modified (diff)
Keywords: gcc44 removed
Owner: changed from macports-tickets@… to mww@…
Priority: HighNormal
Type: submissionenhancement

comment:4 Changed 15 years ago by howarth@…

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

comment:5 in reply to:  4 Changed 15 years ago by 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.

comment:6 Changed 15 years ago by tommccullough-tenica

Cc: thomas.mccullough@… added

Cc Me!

Changed 15 years ago by howarth@…

Attachment: gcc44-config.guess.diff added

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

comment:7 Changed 15 years ago by jschwab@…

Cc: jschwab@… added

Cc Me!

comment:8 Changed 14 years ago by skymoo (Adam Mercer)

Markus, any objections to these changes?

comment:9 Changed 14 years ago by mf2k (Frank Schima)

Cc: macsforever2000@… added

Cc Me!

comment:10 Changed 14 years ago by adfernandes (Andrew Fernandes)

Cc: adfernandes@… added

Cc Me!

comment:11 Changed 14 years ago by adfernandes (Andrew Fernandes)

Updated ppl in #26008

comment:12 Changed 14 years ago by adfernandes (Andrew Fernandes)

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

comment:13 Changed 14 years ago by adfernandes (Andrew Fernandes)

Added port cloog-ppl in #26011

comment:14 in reply to:  12 Changed 14 years ago by 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.

comment:15 in reply to:  13 Changed 14 years ago by 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).

comment:16 Changed 14 years ago by adfernandes (Andrew Fernandes)

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... :-)

comment:17 in reply to:  16 ; Changed 14 years ago by 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.

comment:18 in reply to:  17 Changed 14 years ago by adfernandes (Andrew Fernandes)

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:

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!

Changed 14 years ago by adfernandes (Andrew Fernandes)

Attachment: gcc-graphite.diff added

patch gcc4[456] to add a graphite variant

comment:19 Changed 14 years ago by adfernandes (Andrew Fernandes)

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.

comment:20 Changed 14 years ago by 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).

comment:21 Changed 14 years ago by adfernandes (Andrew Fernandes)

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.

comment:22 Changed 14 years ago by adfernandes (Andrew Fernandes)

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.

comment:23 Changed 13 years ago by jmroot (Joshua Root)

Summary: fixed packaging for gcc44gcc44: disable java multilib

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?

comment:24 Changed 11 years ago by skymoo (Adam Mercer)

Cc: ram@… removed

comment:25 Changed 10 years ago by mf2k (Frank Schima)

Cc: macsforever2000@… removed

comment:26 Changed 7 years ago by kurthindenburg (Kurt Hindenburg)

Owner: changed from mww@… to macports-tickets@…
Status: newassigned
Note: See TracTickets for help on using tickets.