Re: Don't trust your optimizer :-)
On 11/18/2010 23:07, Bart van Ingen Schenau wrote:
On Nov 18, 10:44 am, Daniel Kr?gler<daniel.krueg...@googlemail.com>
wrote:
[..]
I'm not yet convinced that this is true, given the definition of
observable behaviour and the lack of progress guarantees in C++03.
In the software I am currently working on there is an infinite loop
that would cause great trouble if the compiler decided to optimise it
away.
The software runs on an embedded device and the loop is used to
trigger a reset by the hardware watchdog in case some serious problems
are detected (most notably, when a trap from the processor is
intercepted).
I just did a double-check of the implementation of the hw_reset
function, and found that the loop modifies a volatile-qualified
(local) variable, but I can easily imagine such a loop being
implemented without any observable side-effects.
I don"t care to think about what could happen if the compiler
optimised the loop away and the application continues to execute as if
nothing happened.
It would be very helpful, if you could just define the frame code of
main and the infinite loop. There is no need to reveal details, it would
be sufficient to declare some functions that are called during entry and
in the context of the loop or loops and to argue that this is part of an
existing software product.
True infinite loops without "side effects" exist in a very small
subset of legitimate programs. An example given in some thread was a
signal driven program. main was simply:
int main() { for (;;); }
Some signal handlers weer installed, and all of the interesting work
was done in those signal handlers.
Obviously this means that
int main() { for (;;); }
is not a complete example program that demonstrates the defect. Can you
please provide one? Note that a conforming signal handler is required to
perform modifications on either volatile
sig_atomic_t or on lock-free atomic objects, which are explicitly
excluded in above optimization allowance.
How does it matter which observable side-effects occur in code that is
not part of the loop in question?
I don't think that above example program is helpful in this discussion.
If it has any effects they are only relevant outside of the context of
C++ (for the layer that calls the program and waits for the result) and
since we are speaking about C++ here, this is more a form of
philosophization but anything else. Any program makes sense that has any
form of C++ observable behaviour that can be argued about.
And no, I can't provide a complete program that has a legitimate
endless-loop. The embedded software I mentioned above is too large to
post and I don't have the right to publish anyway.
I'm not asking for any form of detailed source code. A basic sketch
concentrated on some loop(s) within main would suffice. It is even more
helpful with your argument that this is part of an existing software
product.
Again, if I'm wrong, please correct me, preferably with a non-
contrived counter-example.
Well, counter examples are much easier to provide. A simple program that
you wrote as
int main() { for (;;); }
can optimize away the end-less loop.
And why is it so great that this loop can be optimised away? What is
the great benefit to the optimiser?
There is no benefit to the programmer, because
- either he intended the loop to finish and is not made aware of a bug
in the program,
- or he intended the loop to be endless and now has to introduce some
bogus side-effects to keep it from being optimised away.
Both committees have *not* specifically provided wording to make exactly
this program transformable in the indicated way (as response to the "why
is it so great" question). But the currently discussed wording *can* be
interpreted to allow this program transformation. This is a gray zone,
if you want. No-one can currently safely proof that the new C/C++
wording would allow to optimize away the empty loop in the above shown
empty program or similar ones.
In fact, it has been explained to me that one of the interesting cases
to support are along the line of the following: Given count and count2
are global variables or variables which are potentially referenced and p
a local variable which is not referenced elsewhere - to be allowed to
transform a local loop
for (p = q; p != 0; p = p->next) {
++count;
}
for (p = q; p != 0; p = p->next) {
++count2;
}
into
for (p = q; p != 0; p = p->next) {
++count;
++count2;
}
Most compilers are not able to proof whether the first corresponding
loop is indeed infinite (e.g. via a circular list). If it would be
required to proof it, the compiler where not allowed to merge these into
a single loop, because that would mean that a legal program could
access or modify count2 by another thread in parallel to the first. In
this case the merge done by the compiler would introduce a data race.
Both standards are not standardizing a new idea. They try to standardize
existing practice. If we don't agree with that direction, we should make
that clear. Objective arguments do help in this discussion.
Last but not least a removal of the whole part 5.1.2.3 p.6 in the
current C draft (n1516) as suggested by a recent proposal
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1509.pdf
would do more harm than good, because this would have the effect that we
decrease the number of constraints to compiler vendors and they could
still interpret all what is currently said in this paragraph (and more).
I don't think that we want this. But if we think that more explicit
wording needs to be added that would forbid the removal of infinite
loops, we should collect some arguments to present to the committees.
This is an invitation to provide any form of data to support or reject
the potential freedom to optimize away some forms of infinite loops. It
is very safe to assume that both C and C++ will follow the same route in
*either* direction, so I think that even pure C programs should be
allowed as reply to this message even in this newsgroup. I hope this is
fine for the moderators as well.
Thanks & 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! ]