clang memory usage vs. gcc (and OS X 10.8, 10.9, ...)

["René J.V. Bertin"]

As mentioned elsewhere, I've just spent several days trying to get the Calligra suite to build against KDE (and other dependencies) through MacPorts (and into /opt/local for those ports not available via MacPorts, like Vc and libetonyek).
I've file a review request (https://git.reviewboard.kde.org/r/116816/) and I'm happy to report that after the last changes pushed to Calligra/Master yesterday a full rebuild took less than 2h using -j3 on my i7 MBP running 10.6.8 (and building on a ZFS filesystem, at that :) ).

There's one catch, though. I use clang to avoid C++ lib clashes on recent OS X versions, MacPort's own 3.3 (because 3.0 has known issues), and it is apparently not quite efficient in its memory usage. There's 1 file in particular, gmic.cpp, that sees VM usage grow to about 20GB at one point, which is never released and may explain why I've always had to kill clang after upwards of 30 minutes of processing (when it in fact appeared to be almost idle).
GCC (MacPorts 4.7) has no such issues, takes less than 2.5GB of memory and terminates in 3-4 minutes to produce a 16MB object file. My Calligra binaries thus run with a gmic module compiled with g++ ...

This is not just an OS X issue; I've tried compiling the file with the same options under Linux, and a similar thing happens. Except that on my Linux box with its hard-wired 10GB of swap, VM usage remains limited to about 7GB.

What do we know about the way clang handles its internal memory allocations and about possible options to limit that?

Also, I understand why GCC cannot be the default compiler to handle the full build process on 10.8 or 10.9 and later. But to what extent would it be possible to resolve the library clash by using clang++ for the link stage when g++ is used for compilation? On 10.6 that appears to be possible without any particular issues but I haven't yet been able to verify this on 10.9 . Thoughts?