[Webkit-unassigned] [Bug 196533] [META] Undefined behavior bugs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=196533

--- Comment #7 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to Yusuke Suzuki from comment #6)
> (In reply to Yusuke Suzuki from comment #5)
> > (In reply to Filip Pizlo from comment #3)
> > > The first of those is just not a bug. CPUs we target ignore the high bits of
> > > a shift amount. This code would only be recompiled if the shift amount ended
> > > up being a constant.
> > 
> > I think the problem of UB is not CPU related thing. CPU behavior is really
> > nice, and meets our expectation.
> > Rather, I think the typical UB-related problem is caused because of the C
> > compiler's assumption "dev never does UB" (clearly, it is wrong).
> > This assumption introduces restriction on some value's range (like, "you are
> > doing "v << x", so, x should be [0, 64), and let's use this information to
> > do further optimizations"), it leads to "aggressively" optimized code, which
> > does not meet our expected behavior.
> > One of the issue I remember is that
> > https://trac.webkit.org/changeset/195906/webkit, GCC leverages our UB
> > behavior and does "optimizations" which makes B3 broken.
> > 
> > My thought on UB is,
> > 
> > 1. If we can easily avoid UB, we should do that.
> 
> In particular, signed integer overflow, 

Possible with -fwrapv and no code changes.

> too large shift amount,

Sounds like llvm should just fix that.  All CPUs we care about agree on the behavior of large shift amounts.  It's dumb that llvm might make the code wrong if you do something that the CPU thinks is right.

> and use of
> uninitialized value.

Sounds like llvm should just fix that, too.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190408/6dd394bf/attachment.html>