Переполнение размера Zerofill в сборке OS X

Предположим, следующий фрагмент кода 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

Это было с системой GCC на Apple Mountain Lion, а именно i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on 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, вероятно, в конечном итоге поднимет это. Вы согласны с этим или я должен подать второй отчет куда-нибудь, чтобы решить эту проблему?