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'.

  ------------------------------------------------------------------------