You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This looks to be a regression by #4152. We actually had a reduction that I later marked as off-topic to the PR, but I think it was just side-stepped. This comment is relevant: #4152 (comment)
The problem lies in how the compiler lowers the loop. The ch payload is desugared as a var ch: <elem-type> whose base backing memory (IrInstSrcDeclVar->ptr) is the i-th element of the array/slice/pointer it's looping on. The index i is increased every loop and so every time ch is dereferenced in the loop body the correct value is used.
Of course this trick falls short once you take into account that a pointer may be allowzero.
andrewrk
added
bug
Observed behavior contradicts documented or intended behavior
stage1
The process of building from source via WebAssembly and the C backend.
labels
Feb 10, 2020
Instead of changing the backing pointer of the variable holding the
iteration value we now load the value from the iterator and store it
into a temporary variable.
This pattern is slightly less efficient when compiled w/o any
optimization but it's always correct, even when the backing pointer is
`allowzero`.
Fixesziglang#4361
Uh oh!
There was an error while loading. Please reload this page.
Reduced from clashos, this may be a regression ¯\_(ツ)_/¯
The text was updated successfully, but these errors were encountered: