c++ - OS X 程序集中的 Zerofill 大小溢出

Question

假设有如下一段C++代码:

char huge[0x900000000];
char large[0x90000000];

在 OS X 上，编译失败(g++ -c filename.cc):

….s:4:zerofill size (2415919104.) <0! Ignored.
….s:4:Rest of line ignored. 1st junk character valued 44 (,).

看汇编代码(g++ -S filename.cc):

    .section    __TEXT,__text,regular,pure_instructions
    .globl  _huge
.zerofill __DATA,__common,_huge,1,5
    .globl  _large
.zerofill __DATA,__common,_large,2415919104,5

.subsections_via_symbols

这是 Apple Mountain Lion 上的系统 gcc，即 i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1(基于 Apple Inc. build 5658)(LLVM build 2336.11.00 )。我还通过 MacPorts 安装了一个版本:g++-mp-4.8 (MacPorts gcc48 4.8.2_0) 4.8.2。有了这个，我得到了基本相同的错误消息，尽管生成的程序集现在看起来像这样:

    .globl _huge
    .zerofill __DATA,__pu_bss5,_huge,38654705664,5
    .globl _large
    .zerofill __DATA,__pu_bss5,_large,2415919104,5
    .constructor
    .destructor
    .align 1
    .subsections_via_symbols

在我看来，所有这些至少都像是一个错误:显然，汇编程序确实将该大小解释为带符号的 32 位数量，而不考虑溢出。不过，我不确定在哪里报告这个问题:这是一个 GCC 错误，要使用 GCC 错误跟踪器报告吗？或者它是 Apple 汇编器中的错误，我应该尝试针对 XCode 或类似的东西报告它？如果是这样，具体如何？或者这实际上是这里使用的 LLVM 软件，我应该在那里报告吗？

那么系统 gcc 在其汇编输出中生成错误大小的事实又如何呢？由于 MacPorts 版本处理得更好，我假设 GCC 开发人员已同时修复此问题，Apple 最终可能会选择它。您是否同意这一点，或者我是否也应该在某个地方提交第二份报告来解决这个问题？

Answer 1

Apple 工程师以这种方式向我的错误报告 #15977897 报告:

llvm-gcc has been unsupported for a couple of years now. Please use clang.

使用 clang 确实有效。至少没有错误消息，目标文件似乎有一个大小合适的 __DATA 段，用 S_ZEROFILL 标志标记。这是我使用 MachOView 发现的工具。 clang 生成的汇编代码看起来也很正常:它具有两个变量的正确大小。