Created attachment 35082 [details] file produced by >gcc -v -save-temps -Wall -Wextra c.cc This crashes mingw g++ (GCC) 4.8.1 XP home SP3 Ubuntu 4.8.1-2ubuntu1~12.04 with s[99999] it hangs. >gcc c.cc -Wall -Wextra >gcc c.cc -Wall -Wextra -fno-strict-aliasing -fwrapv #include <string> struct T { std::string s[4065]; // 4064 is OK }; int main() { T m = {"x", "y"}; } >gcc -v -save-temps -Wall -Wextra c.cc Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --e nable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++ ,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific -runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld -- with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv -prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T Thread model: win32 gcc version 4.8.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-mtune=generic' '-march=pentiumpro' c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/cc1plus.exe -E -quiet -v -iprefix c:\mingw\bin\../lib/gcc/mingw32/4.8.1/ c.cc -mtune=generic -march=pentiumpro -Wall -Wextra -fpch-preprocess -o c.ii ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include/c++" ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include/c++/mingw32" ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include/c++/backward" ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include" ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../include" ignoring duplicate directory "/mingw/include" ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include-fixed" ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../mingw32/include" ignoring duplicate directory "/mingw/include" #include "..." search starts here: #include <...> search starts here: c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include/c++ c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include/c++/mingw32 c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include/c++/backward c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include c:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../include c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include-fixed c:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../mingw32/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-mtune=generic' '-march=pentiumpro' c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/cc1plus.exe -fpreprocessed c.ii -quiet -dumpbase c.cc -mtune=generic -march=p entiumpro -auxbase c -Wall -Wextra -version -o c.s GNU C++ (GCC) version 4.8.1 (mingw32) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130944 GNU C++ (GCC) version 4.8.1 (mingw32) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130944 Compiler executable checksum: 1ebc2a6f92fbd3aadc367a20a63fdf9f
You're creating a huge object on the stack, which is a bad idea, and the problem is probably that GCC is running out of memory.
Also, I noticed that in some cases GCC is able to generate a loop for initialization: #include <string> int main() { std::string m[1000] {"x", "y"}; std::string n[1000] = {"x", "y"}; } That is done in cp/init.c:build_vec_init. But for the original testcase, the loop is not created. Is it a bug?
(In reply to Mikhail Maltsev from comment #2) > Also, I noticed that in some cases GCC is able to generate a loop for > initialization: > > #include <string> > > int main() { > std::string m[1000] {"x", "y"}; > std::string n[1000] = {"x", "y"}; > } > > That is done in cp/init.c:build_vec_init. But for the original testcase, the > loop is not created. Is it a bug? It's a poor optimization choice; we ought to build a loop for member array initialization as well as array variables.
I suspect PR 92385 is a similar issue as here.
Yes this is fixed after the patch for PR 92385 so closing as a dup. *** This bug has been marked as a duplicate of bug 92385 ***