一般来说程序的编译、运行遇到问题，只会怀疑code有问题，而不会怀疑是编译器的问题。不过日子久了，总会遇到各种各样奇怪的问题，最近遇到了两个gcc相关的bug，记录一下。

问题一

在编译一个并不复杂的文件的时候，gcc报内存不够的错误。
这个文件只是定义了一个嵌套了几层的std::map，而且，如果用GCC 4.8来编译，很快就编译完了，占的内存也不多。
然而，如果用GCC 6.2 (或者最新的7.1)来编译，会发现占用的时间非常长，而且占用内存特别多，最终（如果内存不够）会报internal compiler error: Killed的错。
观察发现，在编译的过程中gcc占用的内存越来越多，分配了足够多的swap之后能编译成功，最终内存要占到16~20GiB左右。
同事去submit了一个bug，https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80290，被confirm了。
不过，从comments看，似乎还挺复杂的，什么时候能修好，就难说了。。。
另外，用clang的话也不会出现这个bug。

问题二

在一个动态库里，遇到一个std::unique_ptr相关的segment fault。这个变量在constructor里明明创建过了，但是运行时发现它还是nullptr。
简化一下问题，如果一个动态库里有类似这样的code:

std::unique_ptr<MyStruct> s = nullptr;
void onLoad() __attribute__((constructor));
void onLoad()
{
  s = std::make_unique<MyStruct>();
}

当这个动态库被dlopen的时候，我期望s会被onLoad()初始化好，然而在别的函数里用这个s的时候，会segment fault，因为s里面是个空指针！
关于这个问题，我在SO上提了个问题，结果发现，跟这个GCC的这个bug有关：

简单的说，动态库里 constructor 和 global/static 变量的初始化顺序是unspecified，所以有可能onLoad()先执行，然后再初始化global变量s, 把它初始化成nullptr。注意这个时候只是初始化，原来的变量并不会被析构，其实也是内存泄露。
不过，这个bug看上去暂时不会被修复，只是会在文档里注明这种情况初始化顺序是不定的。
要修复这个问题，需要给变量指定初始化顺序：

std::unique_ptr<MyStruct> s __attribute__((init_priority(101))) = nullptr;

注意init_priority的值设为101~65534都可以。 0~100是reserved，用了会有warning； 最大值是65535，也是默认值，要是设成65535，就和__attribute__((constructor))一样，顺序就变成unspecified了。
另外，clang也支持这个属性，表现也gcc一样，有同样的bug。