Re: Don't trust your optimizer :-)
On 13.11.2010 03:59, Joshua Maurice wrote:
On Nov 12, 7:42 am, Falk Tannh?user<clcppm-pos...@this.is.invalid>
wrote:
Am 11.11.2010 14:02, schrieb restor:
Or, you might want to emulate a program being hung by writing:
for(;;){}
even that can be optimized away. If one of these aspects is crucial to
your program, like times when certain lines of code get executed,
optimizer becomes your enemy: after all its purpose is to change (some
aspects of) the meaning of the program.
The endless loop can't be optimised away by a Standard conforming
compiler, as
it would lead to (potentially observable) execution of the statement
following
the loop.
However, a compiler has the right to optimise away the loop
for(unsigned long long i = 0;
i< std::numeric_limits<unsigned long long>::max();
++i) {}
which otherwise is likely to run until long after we all are dead, even
on a
modern desktop machine. FWIW GCC 4.5.0 does this optimisation when given
-O2 (or
higher) option.
Actually, I wish this was the case.
I assume this refers to the endless loop case, right?
AFAIK, this is the case for C++98
and C++03. However, the wording has been changed in some of the newer
drafts, much to the dismay of many on these boards, including myself.
Specifically, one of the new C++0x drafts specifically says that the
compiler /can/ optimize away endless loops, such as:
for (;;);
Well, this is correct as written, because the loop alone does not induce
observable behavior. Can you give a more specific example program that
would demonstrate such a difference and that would also show that these
rules have negative aspects? For the discussion assume that the most
recently approved constraints would hold as addition to 1.10:
<quote>
The implementation is allowed to assume that any thread will eventually
do one of the following:
* terminate,
* make a call to a library I/O function,
* access or modify a volatile object, or
* perform a synchronization operation or an atomic operation.
[ Note: This is intended to allow compiler transformations, such as
removal of empty loops, even when termination cannot be proven. ? end note ]
</quote>
and assume a strike of the current 6.5p5.
Here's a post I made on comp.std.c++ about the issue. More details can
be found there.
http://groups.google.com/group/comp.std.c++/browse_thread/thread/fb0f396824b
9a801#
I did look into that, but could not find an answer to my previous question.
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]