Conservatively merge pV = &(&Variable) for catch(Variable), EH libs may write the catch value and return the Point (Type**) pV back.
This Point may be dangerously over written due to some work of objects' destructor in try block. (The destructor may work after EH written)
In fact, for the catch point pV, there is usually a very long life range guarded with TIME_START and TIME_END (usually almost through the whole program),
but there is an potion "-stackcoloring-lifetime-start-on-first-use" which will cut it shorter.
This patch try let pV conservatively use its TIME_START and TIME_END as its live-range, not affected by the option "-stackcoloring-lifetime-start-on-first-use"
We find this bug in a big win32 project, which hard to reproduce, now the following case can reproduce.
We also analysis it from front/mid-end, it is hard for front/mid-end to fix this bug, So I continue push this patch go ahead.
Compile with:
clang-cl -m32 -O2 -EHs test.cpp
__attribute__((noinline,nothrow,weak)) void escape(int *p) { }
struct object {
int i;
object() {
i = 1;
}
~object() {
// if "object" and "exp" are assigned to the same slot,
// this assign will corrupt "exp".
i = 9999;
escape(&i);
}
};
inline void throwit() { throw 999; }
volatile int v;
inline void func() {
try {
object o;
throwit();
}
// "exp" is written by the OS when the "throw" occurs.
// Then the destructor is called, and the store-assign
// clobbers the value of "exp".
// The dereference of "exp" (with value 9999) causes a crash.
catch (int &exp) {
v = exp;
}
}
int main() {
func();
return 0;
}
"for which may write memory" is awkward wording. How about "Record the FI slots referenced by a 'may write to memory' instruction?