------- Additional Comments From horst dot reiterer at fabasoft dot com 2004-10-28 14:31 ------- (In reply to comment #3) > The definition of ObjectAddress is incompatible, > there for this is undefined behavior.
You're right, the code relies on undefined behavior. My main question was, why does the compiler choose to implicitly pass by reference? I've done a little more research and found the answer in the GCC changelog: <quote src="gcc/3.4.2/src/gcc/cp/NEWS"> *** Changes in GCC 3.1: (...) * The C++ ABI has been changed so that when a parameter is passed by value, any cleanup for that parameter is performed in the caller, as specified by the ia64 [ / ia32] C++ ABI, rather than the called function as before. As a result, ---> classes with a non-trivial [=non-default] destructor but a trivial [=default] copy constructor will be passed and returned by invisible reference, rather than by bitwise copy as before. <--- </quote> So, the default copy constructor and non-default destructor allow for an optimization as defined in the CXX ABI >= 3.1. Pre 3.1 compilers (including compilers from other vendors, namely ICC <= 7.0 and MSVC) never attempt to implicitly pass by value and compile the code as expected. The basis for the testcase was a C++ application module which had to pass a struct to a C module. Up until 3.0, that worked just fine. With 3.1 and the introduced optimization, the C and C++ ABI diverge from eachother and have become incompatible in that particular pass-by-value case. So, indeed, this is not a compiler problem, it's a feature which changes already undefined behavior for the sake of optimization. As mentioned above, a trivial workaround is to remove the destructor so that the optimization cannot be applied. Thanks for your immediate reply! Cheers, Horst. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18194
