I've simply checked my test results against a run-of-the-mill installation on a redhat linux system for differences... Here are the differences: ----------------------------------------------------------- FAIL: gcc.c-torture/execute/ieee/rbug.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/rbug.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/rbug.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/rbug.c execution, -O2 -g FAIL: gcc.c-torture/execute/ieee/rbug.c execution, -Os FAIL: gcc.dg/980414-1.c (test for excess errors) FAIL: g++.law/profile1.C (test for excess errors) XPASS: g++.robertl/eb132.C (test for excess errors) ----------------------------------------------------------- This is the test summary: === libio Summary === # of expected passes 40 === libstdc++ Summary === # of expected passes 30 === gcc Summary === # of expected passes 7490 # of unexpected failures 16 # of expected failures 7 # of unsupported tests 11 === g++ Summary === # of expected passes 4220 # of unexpected failures 1 # of unexpected successes 2 # of expected failures 84 # of untested testcases 7 -------- Here is the corresponding test under gcc 2.8.1 (the actual numbers differ as gcc does not support -Os) === gcc Summary === # of expected passes 6312 # of unexpected failures 42 # of expected failures 6 # of unsupported tests 11 === g++ Summary === # of expected passes 3622 # of unexpected failures 462 # of unexpected successes 2 # of expected failures 221 # of untested testcases 7 There is one bug in gcc 2.8.1 that also shows up in egcs under standard OpenBSD configuration: if using -finline-functions, gcc emits stabs lines for CTORS at an incorrect position. Hence, the linker no longer finds the CTORS, hence everything breaks down. This has been reported to egcs-bugs. The way we get around this problem is by relying on collect2: egcs is built with use_collect2=yes, so it does no longer relies on stabs for propert CTOR collection, and the bug is no longer visible. Marc Espie