My translation validation tool reports some miscompilations related to the
internal call CLZ(0) when CLZ_DEFINED_VALUE_AT_ZERO is false, but I am not
sure I use the correct semantics...
I started by modeling CLZ(0) as undefined behavior, but that made the tool
report a miscompilation for gcc.c-torture/execute/920501-6.c where sccp
changes a loop to
_36 = t_10(D) != 0;
_35 = .CLZ (t_10(D));
_34 = 63 - _35;
_33 = (unsigned int) _34;
_32 = (long long unsigned int) _33;
_31 = _32 + 1;
b_38 = _36 ? _31 : 1;
This may call CLZ with 0, but the value is not used, so it seems
reasonable to allow this. I therefore changed my tool to treat CLZ(0) as
returning an undefined value instead (by generating it as a symbolic
value, which then makes the tool test that the IR is valid for all
values).
This still makes this optimization fail because the calculation of _34 may
overflow... :( This could be a bug in the sccp pass (which could have
done the calculation as unsigned), but fixing this would still make the
tool report a miscompilation as the ranges calculated during the dom3 pass
claims that _35 has a range:
_35 : [irange] int [0, 63]
So what is the correct semantics for CLZ when CLZ_DEFINED_VALUE_AT_ZERO is
false?
/Krister
