bb8cf5804c
No-op arithmetic simplification will convert expressions like `x += 0` to `x`. When making this simplification, we will also downgrade the ref- kind of `x` from "write" to "read" since the new expression is no longer an assignment. The fuzzer discovered that the ref-kind downgrade was too aggressive, and would also traverse into nested subexpressions and downgrade them as well. That is, for `x[y=z] += 0` would convert both `x` and `y` into "read" references, which is incorrect; `y` is still being written to. The fuzzer managed to turn this mistake into an assertion by leveraging a separate optimization. It added a leading, side-effect-less comma expression for us to detect as worthless and eliminate. In doing so, we clone the expression with the busted ref-kind, triggering an assertion. Change-Id: I42fc31f6932f679ae875e2b49db2ad2f4e89e2cb Bug: oss-fuzz:37677 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442536 Auto-Submit: John Stiles <johnstiles@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
21 lines
735 B
Plaintext
21 lines
735 B
Plaintext
uniform half4 colorGreen;
|
|
|
|
void original_fuzzer_output() {
|
|
float y[8],z;
|
|
z,y[3 .1L[y[7]=y[3],4]]+=0;
|
|
}
|
|
|
|
half4 main(float2 coords) {
|
|
int x[1], y=0, z=0;
|
|
|
|
// This line triggers two optimizations:
|
|
// 1 - No-op arithmetic simplification removes the `+= 0` and changes the ref-kind of `x` from
|
|
// "write" to "read". Crucially, the ref-kind of `y` must remain "write."
|
|
// 2 - Comma-operator simplification detects that the leftmost `0, ` has no side effect and
|
|
// eliminates it. This is done by returning a clone of the right-side expression. The act of
|
|
// cloning the right-side expression can lead to an assertion if `y` has the wrong ref-kind.
|
|
0, x[y=z] += 0;
|
|
|
|
return colorGreen;
|
|
}
|