On 2013-04-22 16:16, "René J.V. Bertin" wrote: >> As said, if there is, this is unsupported. You should instead file bugs >> for the ports that break with clang so they can have clang or broken >> versions of it selectively blacklisted. > > Sure, but apart from that a user can have good reasons to use a compiler > (and/or options) of choice, no? Just one of them: I was amazed to see how > much better autovectorisation has become in gcc 4.7 - in one benchmark of > code taken from Perian, the 'scalar' version of a YUV conversion routine all > of a sudden executed as much faster as a handcoded SSE2 version as that > hand-coded version executes w.r.t. the scalar version using gcc-4.2 or MSVC > 2010 ... > I'm using gcc-mp-4.7 whenever I can ever since, not regretting it a bit.
We do not have resources to handle build errors induced by using various versions of gcc provided by MacPorts. The general use case is to get a working installation. Optimizations of the kind described by you are for intense tasks such as scientific computation or video encoding in multimedia applications. For developers, there is a way to set default_compilers from macports.conf or from the command line to override the automatic detection based on the Xcode version, but that is not in the default configuration file. It is meant for developers only and I expect those who are meant to use this can figure out how it works :-) Also note that the toolchains provided by Apple (both the old gcc 4.2 and llvm/clang) are patched for use on Mac OS X. Most importantly that is the introduction of a driver around the normal compilers invoked with the -arch flags. This allows to build universal binaries in one step, which is not possible with mainline gcc. Using gcc from MacPorts for compiling other ports reduces the available features and makes use of the +universal variant impossible. Rainer _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
