From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) When compiling the actual source code of the mozilla browser (date 2001/03/09), gcc crashes at nsSelection.cpp. Reproducible: Always Steps to Reproduce: 1. Get source from ftp.mozilla.org 2. ./configure 3. make Actual Results: root@titan:/usr/src/redhat/BUILD/mozilla/content/base/src# c++ -o nsSelection.o -c -DOSTYPE=\"Linux2.4\" -DOJI -D_IMPL_NS_LAYOUT - I../../../dist/include -I../../../dist/include -I./../../events/src - I./../../html/base/src -I./../../html/style/src -I./../../xul/base/src - I./../../xul/content/src -I/usr/X11R6/include -fPIC -pthread - DNDEBUG -DTRIMMED -DMOZILLA_CLIENT -include ../../../config-defs.h -Wp,- MD,.deps/nsSelection.pp nsSelection.cpp nsSelection.cpp:441: Internal compiler error in tree_low_cst, at tree.c:4325 Please submit a full bug report. See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions. I have installed gcc-2.96-69
If you can, please try out latest rawhide gcc rpms (-77.1 or -78, whatever is there ATM), plus if you can still reproduce it (or don't have time to check it out), rerun the above command with -save-temps -v options and post here nsSelection.ii it creates.
Created attachment 12564 [details] nsSelection.ii.gz
OK, I have tested it again with gcc-2.96-78, the same error occurs again. I have attached "nsSelection.ii.gz". I seems also that the mozilla source triggers some precompiler bugs (i.e. error on parsing "const xxx = 1 << 3;" in some cases), you should really check it out.
There is something fishy about it: enum { NUM_SELECTIONTYPES = 134667048 }; ... class nsSelection : public nsIFrameSelection { ... nsTypedSelection *mDomSelections[nsISelectionController::NUM_SELECTIONTYPES]; ... }; The size of mDomSelections in bits does not fit into 32bit integer and that's why gcc chokes on it. The thing is how gets NUM_SELECTIONTYPES assigned its value because 134667048 looks completely bogus to me.
Yeah, in the header it's: nsISelectionController.h: enum { NUM_SELECTIONTYPES = 6 };
Chris, are you able to reproduce this? I don't think the preprocessor would just go and replace carefully 6 with 134667048.
I've never seen this problem.
Seems to be influenced by the specific machine configuration. On another machine this problem doesn't occur. Strange, since this is a stable configuration with no special customizations...
The ICE due to the Exceedingly Large Object is fixed in current versions of gcc since Sat Feb 19 18:43:13 2000 Richard Kenner <kenner.nyu.edu> * tree.h (BINFO_SIZE_UNIT, TYPE_BINFO_SIZE_UNIT, DECL_SIZE_UNIT): New. ... which was included in gcc 3.0.