[llvm-bugs] [Bug 43075] Missing return statement causes wrong branch to be taken
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Aug 21 09:42:29 PDT 2019
https://bugs.llvm.org/show_bug.cgi?id=43075
Paul Robinson <paul_robinson at playstation.sony.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
CC| |paul_robinson at playstation.s
| |ony.com
Status|NEW |RESOLVED
--- Comment #1 from Paul Robinson <paul_robinson at playstation.sony.com> ---
> I gather that omitting the return statement in C++ leads to undefined
> behavior, but taking the rtn !=0 branch is still rather surprising.
Undefined behavior is often surprising.
In Clang 7, we observe that reaching the end of the function would be UB,
therefore we are allowed to assume that execution path cannot occur.
However, the "then" branch under the "if" does not have UB, therefore that
must be the path that is taken. We eliminate the unnecessary if (because
we know the "then" branch will be taken) and the printf and exit calls are
executed.
In current Clang, we do a different analysis (or perhaps change the order of
the analyses) to see that "rtn" is guaranteed to be zero when the "if" is
executed, therefore the "then" path is dead code and can be eliminated.
Because reaching the end of the function is still UB, and the only live path
in the entire function goes there, we may assume the function is never executed
and we can eliminate the entire function body.
Fixing your source, as you did, is the correct solution.
Note that if your source had been C code rather than C++, reaching the end
of the function would not be undefined behavior unless the function's caller
attempted to make use of the return value.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190821/ec3000f3/attachment-0001.html>
More information about the llvm-bugs
mailing list