Differences between PGCC and GCC/EMX 2.8.0

Here are the differences between PGCC-1.0 and GCC 2.8.0 The PGCC OS/2 port is based on Eberhard Mattes's GCC/EMX patches (note that I took his name into <EM>...</EM> brackets... guess why ;-), but were (already) heavily modified, so not everything should work as in GCC/EMX 2.7.2.1. There are some small differences which I will list below:

  1. PGCC has NO bound checking.
  2. The symbol __OS2__ is defined if -Zomf is used.
  3. I've removed some of Eberhard Mattes' patches that were related to 8.3 naming convention. FAT is ugly, besides you mostly won't have any problems with 8.3 names even without these patches. They were related mostly to GCC-developer related things, like .cse2, .flow, .combine, .sched and other file name extensions. If you need these files, you should use a normal filesystem :-) (or use EMXOPT=-t)
  4. The -ZC++-comments switch is gone now (hopefully forever) since the preprocessor (CPP) always enable C++-style comments (unless -traditional or -lang-c89 is specified -- and of course unless language itself does not use C preprocessor (CPP)).
  5. The -Zexe switch now works correctly (before it worked only in couple with -o switch). ld and emxomfld were patched too for this (although it is not required). They are as well a part of pgcc-os2-2.95.3-gcc.zip archive. Also now the -Zexe option not only creates a fresh file without extension to keep "make" happy; the behaviour has been changed to copy a file called ldstub.bin that should be located in same directory where ld or emxomfld is into the file with same name as executable but without extension: this avoids two problems at once: first, many "configure" scripts expects after compiling a test program to obtain a *non-empty* file; and second, they expect the file to be runnable, otherwise C compiler is considered a cross-compiler. ldstub determines the name under which it has been launched and launches in turn the executable that has same name but with ".exe" appended. So, for example, if you copy ldstub.bin into "sh" then when you do from, say, bash: 
    [c:/] ./sh
    you will launch "sh" which in turn will look for "sh.exe" (located in same directory as "sh" itself) and will run it.
  6. All compilers were compiled with -Zcrtdll, so you will need an installed EMX runtime to run them. Can't imagine why you need GCC if you don't have EMX :-)
  7. The -mprobe switch is retained for backward compatibility, however it is highly recommended that you use -mstack-arg-probe and -mno-stack-arg-probe instead since these options are new from mainstream GCC version, and maybe someday -mprobe will disappear.

    Another switch that has to do with stack probing is -f{no-}stack-check. These switches have same functionality as -m{no-}stack-arg-probe but uses inline instructions instead of alloca call, so they're faster. Here is how alloca(20000) is compiled with different switches:

    without any switches: 

            subl $20000,%esp

    with -mstack-arg-probe: 

            movl $20000,%eax
        call __alloca

    with -fstack-check options: 

            movl $0,-4392(%esp)
        movl $0,-8488(%esp)
        movl $0,-12584(%esp)
        movl $0,-16680(%esp)
        movl $0,-24392(%esp)
        addl $-20000,%esp
  8. Now alloca() is stack-probe safe, i.e. if you`re compiling with -mstack-arg-probe switch, alloca() will do stack probes for you. However, the previous limitation still applies, i.e. if you will do alloca(4095) twice, this can lead to a crash. The best workaround for this is to not use threads with non-commited stack at all :-)
  9. The provided binaries of GCC will not work in DOS (with EMX or RSX extenders) since they were packed with LXLITE (no OS/2 2.x too). If you need either to run GCC in DOS (note that you still can produce executables that run in DOS), you can try to recompile it yourself. If you want to run it under OS/2 2.x you should unpack executables (lxLite -x -r *). If you can't do the listed above yourself, mail me - possibly if I'll receive enough requests, I'll do a unpacked version. But personally me for DOS am using DJGPP - it is better suited for DOS.
  10. 64-bit ([unsigned] long long) division is now FAST! :-) Its written in assembly now, and I`ve optimized it by hand. It looks almost ~ten times faster as before. Signed division is somewhat slower than unsigned, so if you need speed, use unsigned when possible.
    I should say that same routine, coded in plain C (take a look into libgcc2.c) and compiled with PGCC -O6 is only 10-20% slower (!!!). This makes me think this routine was the last in my life which I've assembled manually ;-)
  11. -mepilogue did not worked in C++ and possibly other languages which mangles names. Now fixed.
  12. _set_new_handler now is called set_new_handler. However, _set_new_handler will work too as an alias.
  13. PGCC has command-line help. Try: gcc --help gcc --help=* gcc --help=-c gcc -h-m gcc -h13.15 There is a new optional environment variable: CLH_TERM. If it is "mono", the help will use only black/white colors; if it is "-", the help won't use highlighting at all; if it is anything other (or is not set) the help text will default to colored syntax.
  14. Libgcc has been put in a separate DLL. I did this since libgcc changes often - with each new major gcc release, sometimes even in minor releases. To avoid conflicts with future/previous libgcc versions, libgcc will have a name consisting of 'gcc' and gcc's internal version number without dots. For example, gcc version 2.90.27 will have its runtime in gcc29027.dll. Do not forget to include this dll with your programs compiled with runtime dlls. If you want to use -Zcrtdll and not depend on gccXXXXX.dll you should link with libgcc by using -lgcc (or -lgpp for C++ programs with exceptions). See also section Tips and tricks.
  15. PGCC has multithreaded support for exceptions. GCC has not.
  16. PGCC has multithreaded libstdc++. GCC has not.
If you remember, some old versions of pgcc had the 'char' variable by default unsigned. I've discontinued this since
  1. This was in contradiction with older versions of gcc/emx
  2. I've realized that not all DOS/OS2 C compilers have the char by default unsigned, how I've thought at beginning.
  3. Many parts of GCC when compiling emits warnings about such things as 'comparison is always X due to argument range limit' etc when char is unsigned. This is not too important, but is somewhat discouraging.
  4. This is a logical continuation of the line 'long long/long/int/short/char'.

Back to PGCC/2 page