On 11/20/13 03:55, Ilya Enkovich wrote:
But it looks incredibly fragile if you ICE once something you don't like
happens. You should be able to easily detect the case and "punt",
that is, drop to non-instrumented aka invalidating bounds.
Actually, it is easy detect such cases and invalidate bounds each time
some optimization bounds data flow. With such feature 5-6 of sent
patches would be unnecessary to successfully build instrumented code
on -O2, but without them quality of checks would be much lower (mostly
due to inline).
It seems to me the right thing to do is warn in those cases where you
have to invalidate the bounds. That's going to be less controversial at
this stage than something like disabling tail recursion elimination.
Those warning sites also form a todo list of things to work on after the
code is integrated and functioning at a basic level. And when the time
comes to work on those problems, we have a reference implementation &
testcase that is dropping to uninstrumented.
For myself at least, that's much easier to deal with because I can throw
the testcase into a debugging session and poke at it. I pick up stuff
much faster that way.
Jeff
