In my global header file: (available on request)
struct Spoint { int x, y, pz; } with pz =>lockup displaying 3dBspline surface
else
struct Spoint { int x, y; } c++ v2b2 comps/runs ok, displaying 3dBspline surface

My 3D graphic engine has operated for some time without problems.
Adding in the pz member causes the program to enter what may be inf'loop ? I can
^c out under fsdb.

I have tried compiling with and without -O optimizations, no difference.
I have changed the struct name from Spoint to ScnPoint & back, no difference.
I have changed the member name pz to z, no difference.
I have tried removing -fsave-memoized, no difference.

Platform = Trident DX4, AMD CPU; under Win 3.11 dos box.

Q:It's as though the compiler corrupts memory meant to be set aside for structs.
This member is the last entry in my longish global header file.

My Makefile follows:
*******************************************************************************

CCAPPL = bspatch

CC=gcx
CFLAGS = -MD -O2 -c -g3 -I. -pedantic -fsave-memoized -m486
C2FLAGS = -MD -O2 -g3 -I. -pedantic -fsave-memoized -m486

LIBS =  -lgrx20 -lgcc -lm -lpc

all:  $(CCAPPL).exe

build:
	$(MAKE) -W obj3d.cc

$(CCAPPL) $(CCAPPL).exe : $(CCAPPL).o obj3d.o objrndr.o userintf.o
	$(CC) $(C2FLAGS) \
		userintf.o $(CCAPPL).o objrndr.o obj3d.o $(LIBS) -o $(CCAPPL).exe

$(CCAPPL).o : $(CCAPPL).cc $(CCAPPL).h gbldecl.h objrndr.o obj3d.o
	$(CC) $(CFLAGS) $(CCAPPL).cc

userintf.o : userintf.cc $(CCAPPL).o gbldecl.h
	$(CC) $(CFLAGS) userintf.cc

objrndr.o : objrndr.h objrndr.cc obj3d.o
	$(CC) $(CFLAGS) objrndr.cc

obj3d.o : obj3d.h obj3d.cc gbldecl.h
	$(CC) $(CFLAGS) obj3d.cc

clean:
	del *.o core

clobber:
	del $(CCAPPL) *.o core

DEPS := $(*.d)
ifneq ($(DEPS),)
include $(DEPS)
endif
*******************************************************************************

This bug appears to have been alleviated for now by removing redundant 
#includes from user headers obj3d.h and objrndr.h .

The redundant includes were stdlib.h stdio.h strings.h & math.h; all
were put in gbldecl.h, but had not been removed from the other headers.

Now the struct pz member is compiling and running ok.

However, the 3d renderer has a few longish inline declared class methods, and
there does appear to be a related problem. One such method, in userintf.cc, 
locks up the c++ compiler when not commented out. There is no indication of what
the problem could be; perhaps the compiler or preprocessor cannot handle too 
many inline declarations and includes ? This is a compile time problem, unlike
the first problem which is runtime; but the compiler could be screwing up
memory layout for the first problem as a result of the same insufficient 
capacity for inlines and includes ?

Chris

My Trident machine has 8 Mb, which may be exhausted during compilation of large
modules with many inline declarations, such as my userintf.cc module was.

Having killed the windows dos box after compilation lock-up, I received a
no DPMI available message when starting another application; possibly
suggesting the compiler had exhausted my 8Mb and therefore locked-up.

My menu class had the long inline method declarations, with the display method
causing the compiler to lock up solid = no indication why.
I've factorised out of userintf.cc my menu class, putting it into separate
header & implementation modules menu.h/.cc .

Compilation of userintf.cc now completes, as does the menu module it uses, 
and all appears to work ok so far.