I tried to make gcc 2.6.3 using the 2.00 beta3 release (djdev200,mak373,gcc263,
bnu252). I used the gcc 2.6.3 source distribution from SIMTEL. After configuring,
I changed the CFLAGS in the makefile from "-g" to "-O2". Then I started "make".
The compiler was able to compile and link cccp, but died when compiling c-parse.c,
after a lot of messages: "out of conventional memory". I had to reset and reboot
the computer. With the original CFLAGS =-g it is able to compile c-parse.c.
I have appended the output of mem/c. As you can see there is 588k conventional
memory available; about as much as you can get. I am using cwsdpmi (beta6) as DPMI
host.
The same problem occurred with the beta1 release.

Any clues or workarounds are welcome!

------------------
OUTPUT of "mem/c":

Modules using memory below 1 MB:
 
  Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  MSDOS       38,701   (38K)     38,701   (38K)          0    (0K)
  HIMEM        1,168    (1K)      1,168    (1K)          0    (0K)
  EMM386       3,120    (3K)      3,120    (3K)          0    (0K)
  4DOS         4,336    (4K)      4,336    (4K)          0    (0K)
  2M           5,280    (5K)      5,280    (5K)          0    (0K)
  RAMDRIVE     1,232    (1K)          0    (0K)      1,232    (1K)
  ADI2         2,384    (2K)          0    (0K)      2,384    (2K)
  POWER        4,688    (5K)          0    (0K)      4,688    (5K)
  DBLSPACE    39,344   (38K)          0    (0K)     39,344   (38K)
  SLCD        23,968   (23K)          0    (0K)     23,968   (23K)
  EANSI        1,936    (2K)          0    (0K)      1,936    (2K)
  MOUSE       14,672   (14K)          0    (0K)     14,672   (14K)
  SMARTDRV    30,560   (30K)          0    (0K)     30,560   (30K)
  MSCDEX      27,984   (27K)          0    (0K)     27,984   (27K)
  Free       614,384  (600K)    602,496  (588K)     11,888   (12K)
 
Memory Summary:
 
  Type of Memory       Total   =    Used    +    Free
  ----------------  ----------   ----------   ----------
  Conventional         655,360       52,864      602,496
  Upper                158,656      146,768       11,888
  Reserved             393,216      393,216            0
  Extended (XMS)     7,181,376    4,043,840    3,137,536
  ----------------  ----------   ----------   ----------
  Total memory       8,388,608    4,636,688    3,751,920
 
  Total under 1 MB     814,016      199,632      614,384
 
  Largest executable program size        602,256   (588K)
  Largest free upper memory block          6,400     (6K)
  MS-DOS is resident in the high memory area.

This bug is a CWSDPMI bug (that's where the error message comes from).
The error went away when the user used b8 instead of b6.  There is a
flaw in the design of CWSDPMI before b8 which uses one locked PT for
each nested image, so you could possibly run out when nesting and/or
locking.  It's still unknown why he ran out earlier than usual - I
expect it's due to an EMM386 bug that mat@ardi.com surfaced (which
for some EMM386 releases lies about the amount of VCPI memory avail).
I suspect the addition of -O2 increased the CC1 memory usage above 
the magical 4Mb virtual mark for the image, which required an extra PT
which was not available.  In any case, I'm working on this for B9
anyway.