gcc报错‘initializer element is not computable at load time’原因及类型转换问题

咱们逐个拆解这些问题，都是很典型的平台特性+编译器规则相关的细节：

1. 为啥int x; int y=&x;会报错？&x哪部分加载时不可计算？ #

先搞清楚核心规则：C标准对全局/静态变量的初始化有严格要求——初始化值必须是「编译时常量表达式」，或者是程序加载阶段（还没跑main函数）就能确定最终值的表达式。

你写的代码里，&x本身是个合法的指针值（如果x是全局/静态变量的话，它的地址是编译时就能确定的），但问题出在类型不匹配的隐式转换上：你要把int*类型的指针赋值给int类型的变量y。在C标准里，这种「指针转非指针算术类型」的操作，不属于编译器能在加载阶段完成的常量操作范畴——尤其是64位系统下，指针是8字节，int是4字节，这个转换涉及截断高位，编译器没法在加载阶段把这个转换后的结果认定为合法的常量，所以就报了“初始化元素加载时不可计算”的错误。

说白了：不是&x本身算不出来，而是把&x转成int的这个操作，不符合加载阶段初始化的要求。

2. 能不能用强制转换让第一段代码编译过？ #

能，但真心不推荐（正如你提到的，这是不良代码）。你可以显式把指针强转成int：

int x;
int y = (int)&x;

gcc这类编译器会认为你明确要做这个转换，会尝试在编译/加载阶段完成（只要x是全局/静态变量，地址可确定）。但要注意：这完全是编译器扩展，不符合C标准，而且64位系统下会直接截断指针的高位字节，导致y的值根本不是正确的地址，属于未定义行为，哪天编译器升级或者换个平台就炸了。

3. 为啥gcc7 x86_64能编译int x; long y=&x;？ #

这是x86_64平台的特性+gcc的扩展：在64位Linux下，long类型的宽度是8字节，和int*指针的宽度完全一致。gcc在这里放宽了规则：当指针转成宽度相同的算术类型时，它认为这个转换可以在加载阶段完成，所以允许这种隐式转换的初始化。

但同样，这不是C标准规定的行为，只是gcc适配平台的一个扩展，换个编译器或者特殊平台（比如某些64位系统下long是4字节，不过很少见）就可能报错。

4. 32位gcc能编译第一段int类型代码的原因？ #

在32位系统里，int和int*指针的宽度都是4字节，此时指针转int的操作，在编译器看来是完全可以在编译/加载阶段完成的——因为宽度一致，不需要截断或扩展，编译器直接把指针的地址数值赋值给int变量y就行，符合静态初始化的要求。

但这依然是依赖平台的非标准行为，属于未定义行为，只是32位gcc允许这种隐式转换而已。

内容的提问来源于stack exchange，提问作者in foq