Thanks for reporting this issue, I see the same problem with SLES11, which comes with gcc 4.3.2.
Note that our next release will support SLES11, but not by using the default g++/gcc library includes since our front end only 4.2 based. We will be supplying our own include files and C++ standard libraries that are 4.2 base.
Note that we reported similar ABI issue in the release notes:
8. Known Issues and Limitations
o The x86 Open64 compiler ABI is designed to be compatible with
the GNU ABI. However, recently an ABI incompatibility
has been uncovered.
The 64-bit ABI used by gcc assumes that the high order 32
bits in %rax are undefined for a function that returns a
32-bit quantity; thus the caller is responsible for
converting %eax into a 64-bit value when the result is
used as an operand to a 64-bit operation.
The ABI used by the Open64 compiler assumes that a
function that returns a 32-bit value will produce a
64-bit extended result in %rax; thus no conversion is
needed when the result is used in a 64-bit operation.
In practice this incompatibility will produce bad results
in rare situations. This issue will be addressed in a
future release of the x86 Open64 compiler.
As your example shows, it is not just 32-bit values are not being properly handled, when later versions of g++ are being used.
Note that we don't see this error on SLES11 SP2 or RHEL 5.3, since the library code for empty zero extends the result:
(gdb) x/5i _ZNKSs5emptyEv
0x316089b5e0 <_ZNKSs5emptyEv>: mov (%rdi),%rax
0x316089b5e3 <_ZNKSs5emptyEv+3>: cmpq $0x0,-0x18(%rax)
0x316089b5e8 <_ZNKSs5emptyEv+8>: sete %al
0x316089b5eb <_ZNKSs5emptyEv+11>: movzbl %al,%eax
0x316089b5ee <_ZNKSs5emptyEv+14>: retq
Your running on Ubuntu 9 right? What version of the g++ are you using?
openCC uses g++-4.2, but libstdc++ is most likely the version that comes with and is compiled with g++-4.3 since this is the standard c++ compiler.
The g++ compile was done using version 4.2.
Out of curiosity: When you provide your own set of libraries, how do you ensure that using pre-compiled libraries with dependencies on the system provided stdc++ will not result in conflicting symbols?
Sorry for the late response.
Note that the major revision numbers of libstdc++.so hasn't changed so the interface as far as g++ is concerned hasn't changed.
Fortunately we have fixed this ABI incompatibility in the compiler that we are just about to release, so there shouldn't be, at least WRT this issue, any problem.
Thanks for reporting this problem, otherwise we probably won't have addressed the issue in time for the release.
thanks you code