https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-10-02
CC| |manu at gcc dot gnu.org
Component|c |middle-end
Ever confirmed|0 |1
--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> The first XLogRegisterData could change the value of xl_xinfo.xid to be
> non-zero, in which case the second XLogRegisterData call would happen
> despite the null string.
This is not what is happening, though. At 083t.fixup_cfg3, GCC does propagate
the null pointer to the call of strlen(). This gets cleaned up latter so that
the whole code boils down to:
void
RecordTransactionCommit(void)
{
return;
}
but not before the ipa warn pass sees the strlen(0). When the first
XLogRegisterData() call is replace by return, the code is simple enough that
the CCP pass before the warning pass is able to simply the whole function to a
return as above, so no warning.
What is interesting is that VRP info already shows that this cannot be zero:
# RANGE [0, 9223372036854775805] NONZERO 9223372036854775807
# USE = anything
_6 = strlenD.895 (0B);
so the warning could be enhanced to look at this info if available (it is
available even at -O1). Or the pass moved later in the pipeline (after fre3).
