CODEWITHSUNDEEP
c++gcccompilation
Prasoon Saurav
Prasoon Saurav

Reputation: 92924

Suboptions for gcc optimization level 1

I have been getting "virtual memory exhausted: Cannot allocate memory" error in one of my project's modules with gcc's -O optimization option. The error go away if I remove -O from the command line.

I checked gcc spec and found that the following options are enabled with -O

      -fauto-inc-dec 
      -fcompare-elim 
      -fcprop-registers 
      -fdce 
      -fdefer-pop 
      -fdelayed-branch 
      -fdse 
      -fguess-branch-probability 
      -fif-conversion2 
      -fif-conversion 
      -fipa-pure-const 
      -fipa-profile 
      -fipa-reference 
      -fmerge-constants
      -fsplit-wide-types 
      -ftree-bit-ccp 
      -ftree-builtin-call-dce 
      -ftree-ccp 
      -ftree-ch 
      -ftree-copyrename 
      -ftree-dce 
      -ftree-dominator-opts 
      -ftree-dse 
      -ftree-forwprop 
      -ftree-fre 
      -ftree-phiprop 
      -ftree-slsr 
      -ftree-sra 
      -ftree-pta 
      -ftree-ter 
      -funit-at-a-time

My new command line has now the following options added

-fauto-inc-dec -fdce -fdefer-pop -fdse -fguess-branch-probability -fif-conversion2 -fif-conversion -fipa-pure-const -fipa-reference -fmerge-constants -fsplit-wide-types -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -fno-var-tracking -fno-var-tracking-assignments but I am unable to reproduce the issue.

Some of the options are unrecognised by the gcc version that I am using (I have removed them from the command line)

gcc -v

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-redhat-linux/4.5.1/lto-wrapper
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i686 --build=i686-redhat-linux
Thread model: posix
gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC)

Can anyone give an idea as to what might be going wrong?

P.S: The code that I am trying to compile has loads of STL stuffs present.

Upvotes: 1

Views: 434

Answers (1)

Toonetown
Toonetown

Reputation: 163

You may want to get a list of the exact optimization options that are being used by your specific compiler. They can vary from compiler to compiler as well as from target to target.

Using the -Q and the --help=optimizers can help you here. For example, let's say you use the following command to compile (and it creates broken code):

gcc -march=armv7-a -mfloat-abi=softfp -mthumb -std=c++11 -FPIC -DNDEBUG -I. -g -c myfile.cpp

And if this command creates working code:

gcc -march=armv7-a -mfloat-abi=softfp -mthumb -std=c++11 -FPIC -DNDEBUG -O -I. -g -c myfile.cpp

You can get the different options by adding in -Q at the beginning of the command and --help=optimizers at the end. For the broken command:

gcc -Q -march=armv7-a -mfloat-abi=softfp -mthumb -std=c++11 -FPIC -DNDEBUG -I. -g -c myfile.cpp --help=optimizers > broken-opts

and the working one:

gcc -Q -march=armv7-a -mfloat-abi=softfp -mthumb -std=c++11 -FPIC -DNDEBUG -O -I. -g -c myfile.cpp --help=optimizers > working-opts

Look for options that are marked as "[enabled]" in the broken-opts file but are "[disabled]" in the working-opts file:

diff broken-opts working-opts | grep '<'

Then, you can either a) compile using -O and disabling the options one-at-a-time (i.e. -fno-option-name for an option called -foption-name) until you find the right one to disable, or you can b) compile without any optimization flags and add the options in one-at-a-time until you find the "broken" option.

I use "broken" option with quotes - because in every case I have ever dealt with, it's actually been a problem with MY code, and not a problem with the compiler or optimizer itself. However, this process has helped me a lot of times to figure out where in my code the problem is (i.e. if the "broken" option has something to do with the stack, or something to do with virtual functions, you can narrow down your search of the offending code).

Upvotes: 1

Related Questions