[Bug c++/29378] The copy constructor is not being called upon return from function calls.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-07 08:17 --- You want to use -fno-elide-constructors. See http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/C_002b_002b-Dialect-Options.html This is not a bug as this is an allowed optimization by the C++ standard. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
[Bug c++/29378] The copy constructor is not being called upon return from function calls.
--- Comment #2 from SSacek at appsecinc dot com 2006-10-07 09:19 ---
Ok, I see that GCC has a work-around for this issue, but I must insist that the
GCC compiler is incorrect in its interpretation of the C++ standard for two
reasons.
1) Optimizations should be allowed for temporary objects only, but not for
named (permanent) objects. Example:
struct S{};
S foo()
{
return S; // this is an un-named temporary object
// optimizations allowed
}
S foo2()
{
S s1; // this is a named permanent object
return s1; // optimizations not allowed
}
The object in foo2() is permanent, and lives and dies in the scope of
function foo2(). Therefore, upon return, the copy constructor must be called,
as well as the destructor.
2) The second reason is that if GCC ignores the programmer written copy
constructors, then the program will be misbehaved, and the results
unpredictable, with even the possibility of a crash. Optimizations are
understandable only if they don't leave objects in unknown states.
The key question here is WHAT IS A TEMPORARY OBJECT ?
I am convinced that the GCC compiler has it wrong, and I have the Solaris and
Microsoft compilers to back me up on this.
Just how many C++ Standards are there?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
[Bug c++/29378] The copy constructor is not being called upon return from function calls.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-07 16:36 --- (In reply to comment #2) Ok, I see that GCC has a work-around for this issue, but I must insist that the GCC compiler is incorrect in its interpretation of the C++ standard for two reasons. The C++ standard is explict. 1) Optimizations should be allowed for temporary objects only, but not for named (permanent) objects. Example: No, because this is a different optimization which is allowed by the C++ standard called return value optimization. 12.8/15 describes this and the second case. 2) The second reason is that if GCC ignores the programmer written copy constructors, then the program will be misbehaved, and the results unpredictable, with even the possibility of a crash. Optimizations are understandable only if they don't leave objects in unknown states. Copy constructor are special for C++. 12.8/15 describes what is going on here. There is only ever one copy of the variable so there is no need to call the copy constructor. The key question here is WHAT IS A TEMPORARY OBJECT ? Yes and the standard is explict that S s3 = f(); might or might not use a temporary object here. 12.2/2 has the example which it explains, the compiler: Also, a temporary might be used to hold the result of f(X(2)) before copying it to b using X's copy-constructer; alternative, f()'s result might be CONSTRUCTED in b. Emphasis is mine. So GCC is correct and so is Sun's compiler and Microsoft's. Just how many C++ Standards are there? Two so far technically but one is just has correction notices from the previous one. Just the C++ standard says is permitted for this case so all three compilers are doing the correct thing according to the standard, just GCC chose to do better optimizations than the other two. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
[Bug c++/29378] The copy constructor is not being called upon return from function calls.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-07 16:55 --- (In reply to comment #2) 2) The second reason is that if GCC ignores the programmer written copy constructors, then the program will be misbehaved, and the results unpredictable, with even the possibility of a crash. Optimizations are understandable only if they don't leave objects in unknown states. Only one object is ever created and will ever be destoried here. So this is not leaving the object in an unknown state because the state is well defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
