This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[3.0, c++, java]: -fomit-frame-pointer IS broken on x86!
- To: gcc at gcc dot gnu dot org
- Subject: [3.0, c++, java]: -fomit-frame-pointer IS broken on x86!
- From: Manfred Hollstein <manfred dot h at gmx dot net>
- Date: Mon, 25 Jun 2001 11:25:13 +0200
- CC: gcc-bugs at gcc dot gnu dot org
- Reply-To: manfred dot h at gmx dot net
Hi there,
I reported this several times already, here it's one again... this
time with some more details.
I just posted three test results from building vanilla 3.0 on Red Hat
Linux 7.1. The only difference between them is that I used different
{CXX,GCJ}FLAGS when building it. This is what I found out:
1. "Standard" flags (althouth more aggressive optimization enabled
for BOOT_CFLAGS) -- see link at
<http://gcc.gnu.org/ml/gcc-testresults/2001-06/msg00507.html> --
show pretty much the same results as reported by others.
2. Adding "-fomit-frame-pointer" to CXXFLAGS and GCJFLAGS results in
many more failures -- details at
<http://gcc.gnu.org/ml/gcc-testresults/2001-06/msg00508.html>
3. Using "-O3" instead of "-O2" for CXXFLAGS results in the following
unresolved symbols when building libgcj.so:
./.libs/libgcj.so: undefined reference to `java::util::Hashtable::getEntry(java::util::Map__U24_Entry*)'
./.libs/libgcj.so: undefined reference to `java::util::HashMap::getEntry(java::util::Map__U24_Entry*)'
./.libs/libgcj.so: undefined reference to `java::util::SubList::checkMod()'
I'm guessing that these are inlined methods (remember, -O3 enables
-finline-functions), which are missing an out-of-line copy.
FWIW, I also reported results with only slightly more aggressive
optimization, and with "-fstrict-aliasing" included for BOOT_CFLAGS,
CXXFLAGS and GCJFLAGS -- details at
<http://gcc.gnu.org/ml/gcc-testresults/2001-06/msg00509.html>;
this only added one more failure for C when compared with 1.:
FAIL: gcc.dg/format/c99-scanf-1.c %hhu sign (test for warnings, line 144)
Getting back to my original problem, since "-fomit-frame-pointer" is
an important flag to achieve acceptable performance of the generated
code on an x86 target, I find it rather bad, that, while performance
is better, correct functionality isn't maintained. This is a diff
between the reported results of 1. and 2.:
82,83c82,83
< CXXFLAGS: -O2 -march=i686 -g
< GCJFLAGS: -O2 -march=i686 -g
---
> CXXFLAGS: -O2 -march=i686 -fomit-frame-pointer -g
> GCJFLAGS: -O2 -march=i686 -fomit-frame-pointer -g
91a92,94
> FAIL: g++.abi/cxa_vec.C Execution test
> FAIL: g++.eh/spec2.C Execution test
> FAIL: g++.eh/spec3.C Execution test
92a96,100
> FAIL: g++.mike/dyncast1.C Execution test
> FAIL: g++.mike/dyncast2.C Execution test
> FAIL: g++.mike/eh33.C Execution test
> FAIL: g++.mike/eh50.C Execution test
> FAIL: g++.mike/eh51.C Execution test
96,97c104,105
< # of expected passes 6481
< # of unexpected failures 1
---
> # of expected passes 6473
> # of unexpected failures 9
116a125,126
> FAIL: gcc.dg/format/c99-scanf-1.c %hhu sign (test for warnings, line 144)
> FAIL: gcc.dg/format/c99-scanf-1.c %hhu sign (test for warnings, line 144)
121,122c131,132
< # of expected passes 15217
< # of unexpected failures 1
---
> # of expected passes 15215
> # of unexpected failures 3
142a153,176
> FAIL: Divide_1 execution from source compiled test
> FAIL: Divide_1 execution from bytecode->native test
> FAIL: Divide_1 -O execution from source compiled test
> FAIL: Divide_1 -O execution from bytecode->native test
> FAIL: G19990302_02 execution from source compiled test
> FAIL: G19990302_02 execution from bytecode->native test
> FAIL: G19990302_02 -O execution from source compiled test
> FAIL: G19990302_02 -O execution from bytecode->native test
> FAIL: G19990303_01 execution from source compiled test
> FAIL: G19990303_01 execution from bytecode->native test
> FAIL: G19990303_01 -O execution from source compiled test
> FAIL: G19990303_01 -O execution from bytecode->native test
> FAIL: G19990303_02 execution from source compiled test
> FAIL: G19990303_02 execution from bytecode->native test
> FAIL: G19990303_02 -O execution from source compiled test
> FAIL: G19990303_02 -O execution from bytecode->native test
> FAIL: G19990304_01 execution from source compiled test
> FAIL: G19990304_01 execution from bytecode->native test
> FAIL: G19990304_01 -O execution from source compiled test
> FAIL: G19990304_01 -O execution from bytecode->native test
> FAIL: InterfaceDispatch execution from source compiled test
> FAIL: InterfaceDispatch execution from bytecode->native test
> FAIL: InterfaceDispatch -O execution from source compiled test
> FAIL: InterfaceDispatch -O execution from bytecode->native test
144a179,198
> FAIL: StringBuffer_1 execution from source compiled test
> FAIL: StringBuffer_1 execution from bytecode->native test
> FAIL: StringBuffer_1 -O execution from source compiled test
> FAIL: StringBuffer_1 -O execution from bytecode->native test
> FAIL: Thread_Alive execution from source compiled test
> FAIL: Thread_Alive execution from bytecode->native test
> FAIL: Thread_Alive -O execution from source compiled test
> FAIL: Thread_Alive -O execution from bytecode->native test
> FAIL: Thread_Interrupt execution from source compiled test
> FAIL: Thread_Interrupt execution from bytecode->native test
> FAIL: Thread_Interrupt -O execution from source compiled test
> FAIL: Thread_Interrupt -O execution from bytecode->native test
> FAIL: Thread_Wait_2 execution from source compiled test
> FAIL: Thread_Wait_2 execution from bytecode->native test
> FAIL: Thread_Wait_2 -O execution from source compiled test
> FAIL: Thread_Wait_2 -O execution from bytecode->native test
> FAIL: Thread_Wait_Interrupt execution from source compiled test
> FAIL: Thread_Wait_Interrupt execution from bytecode->native test
> FAIL: Thread_Wait_Interrupt -O execution from source compiled test
> FAIL: Thread_Wait_Interrupt -O execution from bytecode->native test
156c210,211
< # of expected passes 1676
---
> # of expected passes 1588
> # of unexpected failures 44
159c214
< # of untested testcases 16
---
> # of untested testcases 60
163a219,223
> FAIL: 21_strings/append.cc execution test
> FAIL: 21_strings/ctor_copy_dtor.cc execution test
> FAIL: 21_strings/insert.cc execution test
> FAIL: 21_strings/substr.cc execution test
> FAIL: 22_locale/ctor_copy_dtor.cc execution test
167c227,228
< # of expected passes 245
---
> # of expected passes 240
> # of unexpected failures 5
Another issue is, when "-fomit-frame-pointer" is used alone for
BOOT_CFLAGS, the generated EH stuff in libgcc is broken; adding
"-mno-push-args" cures this problem. I'm not sure, though, if this
is just papering over serious problems wrt/ "-fomit-frame-pointer".
I'm hoping that some x86/c++/eh/java experts will take a look at these
issues.
TIA, cheers.
l8er
manfred