https://llvm.org/bugs/show_bug.cgi?id=28224
l...@joakim.fea.st changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #9 from l...@joakim.fea.st ---
> I guess what I am trying to say is that this bug has nothing to
> do with inlining: imagine that the code in imagine_shift was in
> main because it was written that way.
I don't have to imagine it: I noted in my comment that when I replaced the
function with the exact same code, manual inlining essentially, clang warned
about that expression, while it did nothing if the code was in a separate
function.
Since I noted this behavior on the ldc forum, one of the ldc contributors
pointed me at this old llvm blog post, explaining why llvm doesn't try to warn
about such behavior:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
While there are a lot of arguments there, I don't find the reasoning that "we
simply don't have the internal tracking infrastructure to produce" usable error
messages that follow optimizations from the original code to be convincing. I
think that needs to be done.
Anyway, I suppose the usual argument is that the function is wrong given
certain input and it's not up to the optimizer to flag such bugs, but the code
should have been tested unoptimized to shake out such bugs first. I'll look
into why our debug-mode tests weren't catching this either, that's likely the
real reason this got through.
Of course, many people don't exhaustively test their code and it's going to
make matters worse for them when the llvm optimizer just removes it without a
warning.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
