https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
I've spent a goodly part of the morning pondering this BZ. While I think the
semantics of b_c_p are under/ill defined and they will continue to cause
problems, the as-if rule requires us to not optimize this case until such time
as the semantics are changed.
If look at the observable effects, "b" is not a constant in the source and
b_c_p will always evaluate to zero and we can never call ilog_NaN. After path
isolation, if "a" is zero then we call ilog_NaN. This violates the as-if rule.
So the existence of a b_c_p call (and likely a b_o_s call) in a path means that
path must not be isolated. More generally a block with a b_c_p call must not
be duplicated. That is sufficient to fix this problem. There's a secondary
concern that removing edges which potentially lead to a b_c_p call can cause
similar problems, but I'm inclined to punt that for now.
--
In response to c#7, I'm sympathetic to the behavior you want Marc. But I can't
justify it under the current semantics.
--
I'd love someone to step up and suggest semantics that would allow this kind of
path isolation, but I think that's going to be difficult and the result would
be highly non-obvious to folks trying to use b_c_p.
