This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]