Created attachment 12180 [details]
Small testcase using way too much memory for its size

A post on the FreeBSD toolchain mailing list showed a clang crash due to OOM:
http://lists.freebsd.org/pipermail/freebsd-toolchain/2014-February/001125.html

the log of the build is here (crash is at the end):
http://beefy2.isc.freebsd.org/bulk/head-amd64-default/2014-02-28_01h43m56s/logs/arx-libertatis-1.0.3_2.log

The OP notes an RSS of 15GB.  I did some creduce'ing on his sample files, using clang trunk r202496, and ended up with the attached sample program, just ~100 lines of code.  If you compile this with just -O2, it is very fast to compile, and uses little memory:

$ time -l clang -cc1 -triple x86_64-unknown-freebsd11.0 -emit-obj -mrelocation-model static -O2 too-much-mem.cpp
too-much-mem.cpp:40:1: warning: inline namespaces are a C++11 feature
inline namespace __1 {
^
1 warning generated.
        0.04 real         0.02 user         0.00 sys
     19020  maximum resident set size
     42992  average shared memory size
       101  average unshared data size
       298  average unshared stack size
      1057  page reclaims
         0  page faults
         0  swaps
         0  block input operations
         1  block output operations
        20  messages sent
         0  messages received
         0  signals received
        22  voluntary context switches
         0  involuntary context switches

if you add -g, though, it suddenly balloons to ~2.5 GiB!  E.g.:

$ time -l clang -cc1 -triple x86_64-unknown-freebsd11.0 -emit-obj -mrelocation-model static -O2 -g too-much-mem.cpp
too-much-mem.cpp:40:1: warning: inline namespaces are a C++11 feature
inline namespace __1 {
^
1 warning generated.
        7.87 real         4.26 user         3.53 sys
   2661660  maximum resident set size
     32178  average shared memory size
        75  average unshared data size
       255  average unshared stack size
   1069959  page reclaims
         0  page faults
         0  swaps
         0  block input operations
         1  block output operations
        27  messages sent
         0  messages received
         0  signals received
        30  voluntary context switches
       167  involuntary context switches

I know generating debug information always uses more memory, but this is a little bit ridiculous. :-)

Also interesting is that removing the -mrelocation-model static helps:

$ /usr/bin/time -l clang -cc1 -triple x86_64-unknown-freebsd11.0 -emit-obj -O2 -g too-much-mem.cpp
too-much-mem.cpp:40:1: warning: inline namespaces are a C++11 feature
inline namespace __1 {
^
1 warning generated.
        0.07 real         0.01 user         0.03 sys
     19476  maximum resident set size
     19346  average shared memory size
        45  average unshared data size
       153  average unshared stack size
      1156  page reclaims
         0  page faults
         0  swaps
         0  block input operations
         1  block output operations
        36  messages sent
         0  messages received
         0  signals received
        38  voluntary context switches
         0  involuntary context switches

So this seems to be some sort of bad interaction between the static relocation model and debug information generation?

When building the original testcase from the mailing list, this is all even worse, and it blows up my testing VM before it can compile, having used up at least 8GB resident set size.  Similarly to the minimized testcase, removing -mrelocation-model static allows it to compile, within about 3.5 seconds, and just 91 MiB of RSS.

I can also reproduce these results on Linux, btw, so it is not specifically FreeBSD-related.