Fixes a double free.

Change-Id: Ieb71dff4476132b9b2fb624223e26af49a4131ee
Reviewed-on: https://swiftshader-review.googlesource.com/9728Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Fixes Android Lollipop (and older) build failures.

Change-Id: I30481a59562854b9891a2ac82ac2e7aab8ff570c
Reviewed-on: https://swiftshader-review.googlesource.com/9709Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

libEGL has to call virtual methods on objects created withing libGLESv2,
and vice-versa. Clang's aggressive link-time-optimization considers
calls to these methods unreachable, because they're not defined within
the same linkage unit. So when they do get called, we're hitting UD
instructions. It can be fixed by marking these classes with
[[clang::lto_visibility_public]] attributes:
https://clang.llvm.org/docs/LTOVisibility.html

Bug chromium:720933

Change-Id: I87f9b09921a1b2d443121efcdb5525ff4cb5797b
Reviewed-on: https://swiftshader-review.googlesource.com/9688Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Bug chromium:719291

Change-Id: I5ddf6d45d3a66a4b626ec1d73995a2a4fd4b28b9
Reviewed-on: https://swiftshader-review.googlesource.com/9668Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

EGL does not and should not depend on LLVM.

Change-Id: I36ef1d67e67cdf7625ca8c1a6f1bf3214c39ee4c
Reviewed-on: https://swiftshader-review.googlesource.com/9611Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Direct3D 9 provides support for a "hardware" cursor. There is no such thing
in newer APIs, so we shouldn't waste time dynamically generating code for it.

Change-Id: I8d54c3500966ce075afb83c98c5013024062eed8
Reviewed-on: https://swiftshader-review.googlesource.com/9629Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

C++11 does not allow narrowing a constant expression value to a type
that can't fully represent it. So when char is considered unsigned,
we can't store -1 in it. Explicitly using signed char fixes it.

Change-Id: I5c0e9fe0025659e06291655a12220ab589d5f5bd
Reviewed-on: https://swiftshader-review.googlesource.com/9630Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Bug swiftshader:47
Bug b/37478805

Change-Id: I7519eb7c743530a7bf6a4253244011c29d7ed7c5
Reviewed-on: https://swiftshader-review.googlesource.com/9609Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

The submodule is at /third-party/pnacl-subzero
The subtree is at /third-party/subzero

Bug swiftshader:47
Bug b/37478805

Change-Id: I2da86151f111448e962b6b24c085a2f288de18b4
Reviewed-on: https://swiftshader-review.googlesource.com/9608Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

This fixes a pedantic warning about 'patchSite' being an unused variable.

Change-Id: I2540461fb3da98cebf94350f731fe452e9768b8f
Reviewed-on: https://swiftshader-review.googlesource.com/9610Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Add 'third_party/subzero/' from commit 'fb705a6d'
from repository https://chromium.googlesource.com/native_client/pnacl-subzero

Bug swiftshader:47
Bug b/37478805

Change-Id: I9cc7a7f3d788059984102c8275ec7b28c4b0aad0
git-subtree-dir: third_party/subzero
git-subtree-mainline: 1ba2611b
git-subtree-split: fb705a6d

Bug b/37478805

Change-Id: I3a452410d44c0da1cb01c80e3e4fcade221f7304
Reviewed-on: https://swiftshader-review.googlesource.com/9569Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

ARM does not support shifting by 0. An immediate value of 0 is interpreted as
shifting by 32. See section A8.4.1 Constant shifts of the ARMv7-A/R reference
manual.

Change-Id: I289a7c6091c04387700dc2e9b3f959639bd919ce
Reviewed-on: https://chromium-review.googlesource.com/491949Reviewed-by: Jim Stichnoth <stichnot@chromium.org>

This implementation works by adding a large value which makes the
fractional part no longer fit in the mantissa, and then subtracting it
again. It matches nearbyint() for values up to 2^22, positive or
negative.

The 'magic number' of 0x00C00000 is derived by first observing that the
integer values 0x00800000 to 0x00FFFFFF can be represented exactly in
single-precision floating-point format but can't have a fractional part
because there are 24 mantissa bits (the top one being hidden). So when
adding 0x00800000 to for example 0.6, it forces the hardware to round it
to the nearest representable integer, being 0x00800001. Subtracting 
0x00800000 again gives us 1.0. This works for rounding any value from
0.0 to 0x007FFFFF. However, it doesn't work for negative values, because
the intermediate result would be less than 0x00800000 and thus leave
some room for fractional bits in the mantissa. The solution is to use
0x00C00000 instead so the range gets split between positive and negative
values.

Note that values greater than the upper bound will still round to
integers, but not the nearest ones, while values less than the lower
bound can result in fractional values.

Bug b/37495485

Change-Id: I1aed2d831269fcf21b8d3313856a9b9756a532ef
Reviewed-on: https://swiftshader-review.googlesource.com/9488Reviewed-by: Nicolas Capens <capn@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Some CPU architectures require all memory accesses to be naturally aligned.
We read polygon outline spans in pairs, so we need two underflow spans.

b/37478805

Change-Id: If74fd59654fb6fa56cbed93122b496b9e86dda06
Reviewed-on: https://swiftshader-review.googlesource.com/9528Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Bug swiftshader:41

Change-Id: I4ece1a7aff5cb431ebb80452be0b6698163b7081
Reviewed-on: https://swiftshader-review.googlesource.com/9468Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Change-Id: I57b57f49490b711b9e5d6598a9224f02d5cfa93a
Reviewed-on: https://swiftshader-review.googlesource.com/9490Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Bug b/37478805

Change-Id: Ib3af3edfcc24308b2a0f37cb0f534226aa83e446
Reviewed-on: https://swiftshader-review.googlesource.com/9448Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Bug b/37478805

Change-Id: Idb44b05cea24eed8a46d267c3de9fc769ac58977
Reviewed-on: https://swiftshader-review.googlesource.com/9489Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

When the compiler does not perform return value optimization, the
LockPtr<> destructor of the temporary object is called after the move
constructor has set the Lock to null, thus causing a null pointer
dereference in the destructor. This can be replicated using the
-fno-elide-constructors build flag.

Change-Id: Ie00c3f93364fdf78ea1993469b9a606b3c87ebdc
Reviewed-on: https://chromium-review.googlesource.com/486985Reviewed-by: Jim Stichnoth <stichnot@chromium.org>

This does not provide full support for ARM,
but merely makes things (statically) compile.

Bug b/37478805

Change-Id: I01d1d84e396c04c84e74d521946595014d2eafb5
Reviewed-on: https://swiftshader-review.googlesource.com/9430Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

x86 does not strictly require this because it performs snooping to ensure
consistency, but it is essential on ARM and some other architectures.

Bug b/37478805

Change-Id: I9fad94571ec65b67132ba40c3e1814c63d6af468
Reviewed-on: https://swiftshader-review.googlesource.com/9429Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Bug chromium:710753

Change-Id: Ie74d86de027417579c9c6949aabad1c3ae89ebfc
Reviewed-on: https://swiftshader-review.googlesource.com/9329Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Writing or reading an ordinary volatile boolean does not provide memory
ordering guarantees. Use atomic<bool> with release and acquire semantics
instead. On x86 this should have no impact on the generated code, since
it architecturally offers strong memory ordering guarantees.

Bug chromium:710753

Change-Id: I5aa2a6eeecfcd691a0aa8d06fd067f9d59ab13c3
Reviewed-on: https://swiftshader-review.googlesource.com/9328Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

BUG=chromium:686980

Change-Id: I5f22f57288246c262a0fdb0ca1b0b321e4a58c1b
Reviewed-on: https://swiftshader-review.googlesource.com/9310Tested-by: Ivan Krasin <krasin@chromium.org>
Reviewed-by: Nicolas Capens <capn@google.com>

BUG=chromium:686980

Change-Id: I0224093fbbffb2bac8a84c95a8370617c4df6978
Reviewed-on: https://swiftshader-review.googlesource.com/9309Tested-by: Ivan Krasin <krasin@chromium.org>
Reviewed-by: Nicolas Capens <capn@google.com>

Linking libEGL.so of the SwiftShader's flavor requires
the linker to be too smart (there's a heavy reliance on
garbage collecting unused symbols, for which there is
no guarantees in the general case). In ThinLTO case,
garbage collection is still not as sofisticated, as in
other cases, so it fails to link the target complaining
about undefined symbols.

The workaround is to prevent Clang from splitting the
bitcode files in the question into two, and making the
GC problem a bit easier.

Eventually, ThinLTO might get a better GC, but it might
be a good idea to not rely on this feature in the source
code. At least, no other targets in Chromium do.

BUG=chromium:686980

Change-Id: Ib44f65c4825cc3f6cd24695738a71ca4661f0bfb
Reviewed-on: https://swiftshader-review.googlesource.com/9308Tested-by: Ivan Krasin <krasin@chromium.org>
Reviewed-by: Nicolas Capens <capn@google.com>

Bug chromium:712624

Change-Id: I8e7813aac44c9fef1a2311be550da8cea5a65d16
Reviewed-on: https://swiftshader-review.googlesource.com/9330Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Bug b/31913614
Bug b/32087196

Change-Id: I45c06c7cb907ae1f1efc57c6302044334159c828
Reviewed-on: https://swiftshader-review.googlesource.com/7734Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

The EGL_ANDROID_framebuffer_target extension description is vague about
which configs are supposed to have the EGL_FRAMEBUFFER_TARGET_ANDROID
attribute set. The HWComposer isn't supposed to do format conversions,
nor should we have to blit or convert on eglSwapBuffers, so the flag
is only set when the config's format matches the framebuffer format.

Bug b/21804123

Change-Id: Ie348750fbf1b2f096cdf36358d5c90b6f42e30c1
Reviewed-on: https://swiftshader-review.googlesource.com/8933Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Change-Id: I97f30a38f2f78ae5c4e2be8899dae3c8ff8bc748
Reviewed-on: https://swiftshader-review.googlesource.com/8968Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

- Implemented GL_EXT_color_buffer_float.
- Removed duplicate glRenderbufferStorageMultisample implementation.
- Refactored internalformat validation.
- Removed GL_R11F_G11F_B10F as renderable format. OpenGL ES 3.0 only supports
  this as a texture format.

Change-Id: I83ce8225c1b310006f5ce983349ea8cb8b2f7c29
Reviewed-on: https://swiftshader-review.googlesource.com/9048Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Textures with just one texel don't require filtering. This also avoids precision
issues for pedantic tests which expect exact values.

Bug swiftshader:39

Change-Id: I52c5697e277523e2b8cb2c879ba0a7b2296ee7c5
Reviewed-on: https://swiftshader-review.googlesource.com/9068Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

For OpenGL ES 3.0, the varyings limit must be increased in order
to meet the new lower limit. This doesn't solve how the varyings
count is still verified at compile time instead of link time, but
it allows us to remove an UNIMPLEMENTED() call.

Bug b/37069434

Change-Id: Ib6641352b625d56c7c3cab119fadcdc19f794a5b
Reviewed-on: https://swiftshader-review.googlesource.com/9188Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

These tests rely on the SwiftShader libraries to be loaded from a swiftshader/
subdirectory. The PowerVR samples are a better smoke test for the standalone
build, so we can just remove the Chromium unit tests from the Visual Studio
solution.

Bug swiftshader:42

Change-Id: Ia7d73a62aac4a202750e630666143c920fec65b7
Reviewed-on: https://swiftshader-review.googlesource.com/9268Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Change-Id: Idc8f54ac36e59640b93af83293dc2339a25336d6
Reviewed-on: https://swiftshader-review.googlesource.com/9208Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

This test verifies that the swiftshader EGL libraries exists, can be loaded, has
its entry functions accessible, and we get the expected vendor/version strings.

Change-Id: Ifc29286cfaa83fa4c2412c073d383f2c1b58766f
Reviewed-on: https://swiftshader-review.googlesource.com/9168Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Change-Id: Ie546d41b0205c7bd963a56af209652fd41fbe3ca
Reviewed-on: https://swiftshader-review.googlesource.com/9128Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Change-Id: Ib13af2fb929df98e0bb0e5af33a935942d854706
Reviewed-on: https://swiftshader-review.googlesource.com/9008Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>
(cherry picked from commit 2aeaa6f445b1878a1ee3986c3b08ffa50323b366)
Reviewed-on: https://swiftshader-review.googlesource.com/9108Reviewed-by: Alexis Hétu <sugoi@google.com>

By default we build SwiftShader with the LLVM backend, so the build
shouldn't fail because of missing the Subzero submodule's code. Run
git submodule update --init
To pull the submodule if you do want to build with Subzero.

Change-Id: Ib752edf891a6dd18fff8ce0dfae79ff5a1b7e011
Reviewed-on: https://swiftshader-review.googlesource.com/9088Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>