gcc занимает много памяти для компиляции файла c ++ с очень большим объектом в стеке - PullRequest
Новая
       19

gcc занимает много памяти для компиляции файла c ++ с очень большим объектом в стеке

2 голосов
/ 14 апреля 2019

У меня есть файл C ++, который использует std::bitset<size>. При компиляции с использованием gcc в Linux-подсистеме Windows, если size = 1000000000 (1 Гбит) вызывает около 1,6 ГБ памяти, используемой во время компиляции, size = 10000000000 (10 Гбит) приводит к ~ 6 ГБ памяти и ~ 15 ГБ виртуальной памяти (на моем компьютере всего 8 ГБ памяти). ). Память распределяется постепенно, и компиляция заканчивается сразу после максимума. Программа запускается в Segmentation fault (core dumped) сразу после запуска, если size большое. Поворотная точка находится между 10M и 100M.

В MSVC программа компилируется и работает нормально, если size мало. Для больших size выдается исключение: «Переполнение стека». Если значение size действительно велико, выдается ошибка «общий размер массива не должен превышать 0x7fffffff байт» в файле bitset

Проблема не имеет отношения к уровню оптимизации. Неважно -O0, -O1, -O2 или O3, это то же самое.

это вывод gcc -v: 

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)

Это мой тестовый код, очень простой 

#include <bitset>

int main(){
    const size_t size = ...;
    std::bitset<size> bs;
    return 0;
}

Если вместо gcc-7 используется gcc-8, такой проблемы не возникает, компиляция заканчивается быстро, и программа сталкивается с ошибкой сегментации, если size велико, как и должно быть. Если я использую vector<bool> или создаю набор битов, используя new, он работает хорошо.

Так что нет проблем для решения, но мой вопрос:

Почему gcc-7 требует столько памяти (и времени) для компиляции файла?

1 Ответ

1 голос
/ 14 апреля 2019

Это была известная ошибка в GCC, связанная с constexpr инициализацией очень больших объектов.

Существует несколько отчетов об ошибках, одним из которых является ошибка 56671 , о которых сообщалось в марте 2013 г. против v4.7.2. Ошибка была помечена как исправленная в июне 2018 года, что означает, что она присутствовала, по крайней мере, до v7.3, но теперь исправлена.

Если вам нужен обходной путь, похоже, что использование другого конструктора не вызвало ошибку. В частности, изменение std::bitset<size> bs; на std::bitset<size> bs(0); прекрасно компилируется на различных версиях gcc, включая v.7.3.0 (в соответствии с онлайн-компилятором, который я пробовал).

...