Issue title: R48 introduced regression in expr for YUV420P8 clips
 Issue body: I've run into a bug with R48 that seems to trace back to expr. Essentially, expr produces a green clip, instead of black and white, for YUV420 clips. The bit-depth of the clip doesn't seem to matter.

The following script can reproduce it on my ubuntu18.04 machine using an AMD Phenom 1090t. Either uncommenting the SetMaxCPU or switching to the default (RGB) clip produces a black clip. Otherwise the output is green:

```
import vapoursynth as vs
core = vs.get_core()
#core.std.SetMaxCPU("none")

#clp  = core.std.BlankClip()
clp  = core.std.BlankClip(format=vs.YUV420P8)
clp1 = clp

expr = 'x 3 + y < x 3 + x 3 - y > x 3 - y ? ?'
clp = core.std.Expr([clp1, clp], expr=[expr])

clp.set_output()
```
This results in corrupt output for QTGMC, as expr is used to process the input for motion compensation functions. Thanks to HolyWu, I can work around it by setting core.std.SetMaxCPU("none"). I did not have this issue with R47.2, and can also work around by rolling back.

Let me know if I can provide anything else to assist in debugging.
 Comments: 
 Comment 0: I can't reproduce. Does this happen on other CPUs?
 Comment 1: Also can't reproduce it here using vdub2 to view the output.
 Comment 2: I attempted to run VMs on virtualbox with different cpu_profiles to emulate other CPUs without success, meaning the VMs won't load.

Is there anything else I can provide you folks with to assist in debugging?

Is this a case of an older CPU introducing irregularities?
 Comment 3: Do you not have access to any other CPUs than Phenom? For example, Core 2, i3;/5/7, etc. And are you using a 32-bit or 64-bit build?
 Comment 4: Reproduced on x64 kubuntu running in a VM.
 Comment 5: @chriskretler more details please, reproduction is really spurious
 Comment 6: @myrsloik I'm happy to provide more. Do you want environmental information, or more information on the test case?
 Comment 7: The following steps can assist in reproducing the issue and ultimately fixing it:

(1) Sharing your VapourSynth binary (libvapoursynth.so). Please share unstripped binaries.
(2) If unsuccessful, we may need remote access to your computer to reproduce the issue.
 Comment 8: The requested file can be found here:
https://www.dropbox.com/s/nkvnlti0oztj3ff/libvapoursynth.so?dl=0

For what it's worth, I can create an environment that reproduces the error via the vagrant environment as defined here:

https://github.com/chriskretler/vsynth-env-provisioning


 Comment 9: I tried to use your binary but still could not reproduce on my system.
 Comment 10: Arggh, you're right. That was a 47.2 binary.

I've rebuilt R48 and uploaded the binary to dropbox. It is available via the same link.
 Comment 11: I tried with the new binary. It is R48, but I still can't reproduce the issue. I ran the script in the OP and the chroma planes are 0x80 as one would expect.
 Comment 12: Given that setting:

core.std.SetMaxCPU("none")

eliminates the issue for me, I'm comfortable assuming I am seeing this due to my older CPU.

One last question: what version of zimg are you running?
 Comment 13: I used the Git master of zimg, but it is not relevant to your script, since only BlankClip and Expr are invoked. Even if the issue is specific to your CPU, we do want to understand the root cause. Does the green clip reproduce 100% for you?
 Comment 14: Ahah, found the bug. Fix is checked into master.
 Comment 15: That's great news sekrit. Thank you for sticking with it.
 Comment 16: I will test soon.
 Comment 17: Confirmed fixed in master. Thank you for your diligence sekrit.
{'source': 'GithubIssues', 'repo_name_with_owner': 'vapoursynth/vapoursynth', 'issue_id': 573628618, 'repo_stars': 1188.0}