Getting started

• High portability. GCC runs today on a huge number of architectures and operating systems. Here's a list of only the CPU types supported by gcc (this is a simple listing of gcc/config/*):
  1750a, a29k, alpha, arc, arm, avr, c4x, clipper, convex, d30v, dsp16xx, elxsi, fr30, h8300, i370, i386, i860, i960, ia64, m32r, m68hc11, m68k, m88k, mcore, mips, mn10200, mn10300, ns32k, pa, pdp11, pj, romp, rs6000, s390, sh, sparc, v850, vax, we32k
  Not mentioning that for many CPU types, gcc supports more than one operating system (e.g. x86).
• Standards. GCC developers try to keep close to the respective language standards (unlike some other C compilers which have a whole heap of doubtful language extensions), thus ensuring a high degree of language compatibility. Besides, gcc has the "-ansi" switch, which ensures 100% compatibility with ANSI C/C++, disabling all platform-specific extensions.
• Optimizer. Of all the compilers I have seen, GCC has the most sophisticated optimizer. For the x86 platform, gcc has switches for optimizing code for every major CPU type - from i386 to Athlon and Pentium Pro.
• Features. Of all the compilers I have seen, GCC has the largest number of switches, allowing you full control of how exactly the code is being generated, of language dialects, which warnings are emitted, and how preprocessing is done.
• Open source. GCC is one of the first free C/C++ compilers. You can get its source code and see how something works exactly - if you still have questions after reading the very detailed and high-quality documentation. You can fix a bug if you find one - without having to wait months for "service packs". You can participate in its developement.

Installation and Configuration:

Download site

Compiling our First C++ Application with New GCC

#include <iostream.h>
using namespace std;
int main()
{
cout<<"Hello World"<<endl;
return 0;
}

Now let's compile this by launching g++ test.cpp. No problems, but we get an a.out object file in this example. Let's use OMF.

g++ test.cpp -Zomf

You will get a lot of linking errors, for example:
X:\......\gcc-lib\i386-pc-os2_emx\3.0.2\st\stdcxx.lib(functexcept.obj):
error L2025: _ZTSSt9exception : symbol defined more than once

Bad indeed. This happens because linking with the libstdc++ library requires special handling when using OMF format. Erase weaksyms.omf from the current directory. Go to emx\lib\gcc-lib\i386-pc-os2_emx\3.0.2\ and copy weak symbols list file from there (weaksyms.omf) to your directory. Issue the compilation command once again. It should work as expected this time.

Here is how it works. As many people know, gcc never generates OMF files directly. Instead, it generates a.out files which then are run through emxomf in order to convert them from a.out to OMF. Finally, in the link stage, LINK386 or ILINK is run. Now, the weak symbol attribute has an effect at the link stage. Having a symbol marked as weak means that if there is another symbol with the same name and also marked as weak, a duplicate symbol error is not generated. Instead, the linker randomly chooses one of them (usually the first one encountered.) (In fact, the "real" weak attribute also means that if somebody refers to a weak external symbol, and that symbol is not found anywhere, it is resolved to NULL. But this syntax of weak symbols is supported only in the a.out format, not OMF.) The only way to do it for OMF is to keep a list of weak symbols of your project in a external file, which is not lost between numerous runs of emxomf. Suppose emxomf converts an a.out file to OMF and finds a weak symbol. Now it looks into that table: have we encountered this weak symbol already, or is this the first time? If we encountered it already, the symbol is converted to a non-exported local symbol (so that LINK386 won't barf about duplicate symbols.) If not, the symbol is marked as a normal symbol, and it is added to that external table, along with the object file name where it was encountered for the first time. The file name is needed so that when the same file is re-compiled (for example after you modify the source) emxomf should detect that this symbol should be declared as external and not as a local non-exported symbol, even though it is mentioned in the weak symbol table. This file is called weaksyms.omf. If you see such a file in your project's directory, it means your project uses weak symbols. Don't delete it, after some time it will cease to grow and it will contain a complete list of weak symbols of your project. If your project uses multiple directories, and your makefile changes the current directory then emxomf can miss the weaksyms.omf file and start the list from scratch. In this case you can get duplicate symbols error. The solution is to maintain one unique weak symbol list by setting the GCC_WEAKSYMS environment variable which points to some file where all your weak symbols will be collected:

SET GCC_WEAKSYMS=d:/myproject/weaksyms.omf

Q)Compiling speed is slow.
A)Use SET GCCLOAD=x, where x is a number of minutes to keep GCC pre-loaded in memory. Also use -pipe switch while compiling, or SET GCCOPT=-pipe.

Q)Fork does not work anymore in GCC 3.0.2. Why?
A)Not exactly. It does not work when using the -Zcrtdll switch. This happens because EMX's fork() black magic gets confused by the new gcc302*.dll. If you add the "-lgcc" switch after -Zcrtdll, your application won't be linked against gcc302*.dll, and fork() will work.

Q)I can't allocate more than 32 Mb of memory. What to do?
A)That's an EMX feature. Usually EMX applications are limited to using a 32MB heap because the fork() logic expects the heap to be allocated in one big segment. If you don't use fork(), you can use the _uflags() function to tell the EMX runtime that you don't want your heap to be contiguous.

Q)What OS/2 specific macro symbols does GCC 3.0.2 define?
A)You can see these by running gcc -v on a .c or .cpp file. The OS/2-specific symbol is __OS2__, also __EMX__ is defined; other symbols like __i386__ are defined depending on CPU type.

Q)GDB does not find my function names!
A)g++ 3.0 and later has a new name mangler. This means that gdb and other old apps cannot demangle the mangled C++ names correctly. There is nothing you can do about it other than trying to port a newer gdb (:-).

Q)-mcpu=pentiumpro does not accelerate my app. OS/2 bug?
A)The speed increase is marginal and can give significant increases only for computational algorithms. Normal programs are limited by lots of other factors, thus pure execution speed is not a requirement for most programs. In fact, I'd recommend everyone compiles using the -O2 -march=i386 switches, because these two switches favour small code size over speed, and you won't observe any differences anyway.

Q)Executable size is sooooo huge. How to reduce it?
A)You can try to use the -Zcrtdll switch. Also if your project is written in C++ and you don't use exceptions, you should use the -fno-exceptions switch: this will reduce your executable size a lot. Also -fno-rtti could give a small gain. Finally, try -Os switch which tells gcc to optimize by favouring smaller code over faster but larger code.

• The OS/2 port of gcc (and only it) has a new flag: -malign-strings. By default gcc used to align all string constants on a 32-byte boundary (!) which is quite too much IMHO. I've added a CPU-type-dependent alignment (4 bytes for 386/486 and 32 bytes for Pentium and later) and also added the -malign-strings=x switch to override this default. `x' is a power-of-two, e.g. -malign-strings=5 will align on 32-byte boundaries (the default value with -mcpu=pentium). The compiler itself is built with -malign-strings=0, which alone made the C++ compiler cc1plus.exe about 150K smaller! It looks like there is someone in the GCC team who works for Intel and has the goal of making gcc generate extremely bloated code. This 32-byte alignment is said to be `extremely' useful on Pentium III when doing inline strlen's and strcmp's. Phuf. If someone cares about that `gain', use -mcpu=pentium or -mcpu=pentiumpro. You can still optimize for pentium and not align strings (because you either know strlen speed is not critical or you simply don't do strlen on static strings) by using the -malign-strings flag (in fact, all the compilers were built this way -- most static strings here are just messages.)
• gcc 3.0 has the annoying habit of aligning its stack boundary to 128 bits (e.g. 32 bytes). This generates generally larger files. To avoid this, use -mpreferred-stack-boundary=4 or whatever you like (the argument is in bytes). The 32-byte stack alignment makes sense only when using SSE instructions (but is always enabled, no matter whether you use them or not.)
• The default CPU type is Intel 386. You can generate faster (but generally larger) code by using -mcpu=xxx where xxx is one of (as of gcc 3.0.2): i386, i486, i586, pentium (=i586), i686, pentiumpro (=i686), k6, athlon.
• On all Intel CPUs later than i386 and Athlon the default alignment for functions, loops, and jump labels is 16 bytes, and for K6 it is 32 bytes!. This can generate lots of unused space (NOPs) in your executables, especially if you use lots of small functions. and many loops and labels. If you use -mcpu=xxx and you care for space more than for speed, use the -malign-loops=2 -malign-jumps=2 and -malign-functions=2 switch, which will align everything on a double word boundary.
• The semi-legendary MMX and SSE support which is mentioned in the documentation does NOT mean that gcc generates SSE or MMX from C/C++ code. This just means that you can use a number of special gcc builtin functions such as __builtin_ia32_emms(), __builtin_ia32_psllw() and so on instead of writing directly __asm("emms") etc. Of course, it is nicer to write MMX code in a C-looklike manner than directly in assembly language (especially since GAS uses the hard-to-understand for those who're used to Intel syntax, AT&T syntax) but you have to get from somewhere the respective header files and/or docs (I believe they should exist somewhere in the Linux world).