With a 4.8-based compiler for ARM, I've observed an ICE in the
var-tracking.c:add_stores handling of COND_EXEC. A large testcase
from building Qt can be found at
<https://bugs.launchpad.net/gcc-linaro/+bug/1312931>; a somewhat
reduced version (for the compiler with which I observed the problem)
is attached (to be built with -march=armv7-a -S -g -O2 -std=c++0x
-fno-exceptions -fPIE), but the issue seems very sensitive to details
of optimization and the test not really suitable for the testsuite.
The assertion
gcc_assert (oval != v);
fails. As I understand it, this is asserting that the conditional
store is not storing a value already present in the location in
question. Now, it's not clear to me this should be relying on
optimizations like that. In this case, the key peculiarity of the
code that may have caused the lack of optimization involves the
shared_null static const data member. The destination of the problem
conditional store holds a value loaded from that member at some
point. The source of that store was previously (conditionally, on the
same condition) stored into that constant location. (Maybe in the
original code this store into a const location can't actually occur,
but that's the code being processed after inlining.) So if you treat
that location as constant it follows that the two values are the same
(and that we have undefined behavior at runtime), while if you don't
then the values are clearly different (the store ends up being a
conditional increment).
This patch simply makes add_stores do nothing in this case of a
conditional store that does nothing.
Tested with no regressions for cross to arm-none-linux-gnueabi. OK to
commit?
2014-06-27 Joseph Myers <joseph@codesourcery.com>
* var-tracking.c (add_stores): Return instead of asserting if old
and new values for conditional store are the same.