Sanitizer tools desire having the vtables of any class with non-pure
virtual methods, even when none of them are called in the current
linkage unit. Work around this by making the affected classes pure
abstract and implementing them in a derived class in the respective
library responsible for creating them.

Bug swiftshader:31

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

Sanitizer tools desire having the vtables of any class with non-pure
virtual methods, even when none of them are called in the current
linkage unit. In the case of sw::FrameBuffer, to work around this we can
make the class pure abstract by making the destructor pure virtual. Note
that the destructor still has a non-empty definition, since all non-
default destructors need a defintion, and it will get called as part of
the destructor chain.

Bug swiftshader:31

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

These were already available for GLES3 and exposed as texturable
formats for GLES2 when the GL_EXT_texture_rg extension was exposed,
but it should also have enabled these formats as renderable formats.

Bug swiftshader:60

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

This is required by chromium tests. There is another cl
(https://swiftshader-review.googlesource.com/9952) which
will change internal uses of OUTLINE_RESOLUTION to adapt
to the rendertarget's height which will reduce the memory
usage increase caused by the current cl.

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

In EGLQueryString, it is now valid to query EGL_EXTENSIONS
with a display set to EGL_NO_DISPLAY, so the function
should proceed without returning an error in these cases.

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

The extension was already implemented for GLES3, but simply required
a few cases to be added for support in GLES2.

Note that this extension is required to process filters using masks
with GLES2 in skia.

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

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

Bug chromium:729532

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

Recently, ES3 specific getIntegerv queries were removed from ES2.
Unfortunately, GL_MAX_COLOR_ATTACHMENTS was moved to the ES3
section, but was still supposed to be in the ES2 section,
since the GL_EXT_draw_buffers exposes it.

Change-Id: I2272ccf282558e10ee6cfb1be9d124cc59df14fa
Reviewed-on: https://swiftshader-review.googlesource.com/9911Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Bug b/38514001

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

TableGen uses exceptions, but is not used.

Change-Id: I3a54c2f72784169804b3305c26f17c63c313931e
Reviewed-on: https://swiftshader-review.googlesource.com/9851Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Lingfeng Yang <lfy@google.com>

Bug b/38268007

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

bug: 38257724

With this CL, dEQP-GLES3.functional.shaders.functions.invalid no longer results
in a stack overflow and system crash.

The fix is to explicitly loop over switch cases in the function call
depth analysis.

Later on, we probably want to change TIntermSwitch traversal to loop
over all cases of the switch statement as well, but that requires
a lot of changes; all traversers need to be changed to not have to loop over
switch statements themselves, which will break expectations and
perhaps functionality that critically depends on seeing/controlling iteration
over switch statement cases.

Not tested for regressions in dEQP-GLES2.functional.shaders.*

Test: dEQP-GLES3.functional.shaders.functions.invalid.dynamic_switch_recursion_vertex:
system crash, hang, or fail -> Pass

Change-Id: I5d13a5f3296579c8818975e103f5ed6e03a47b68
Reviewed-on: https://swiftshader-review.googlesource.com/9789Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Lingfeng Yang <lfy@google.com>

Bug b/38257724

Change-Id: I4157ef825ed4ed8f805e9dad35b43bb5780877b6
Reviewed-on: https://swiftshader-review.googlesource.com/9788Reviewed-by: Nicolas Capens <capn@google.com>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Tested-by: Lingfeng Yang <lfy@google.com>

Bug b/17893069

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

If the EGLDisplay input parameter to eglInitialize isn't
PRIMARY_DISPLAY or HEADLESS_DISPLAY, egl::Display::get()
will return null. Instead of crashing, we should return
an EGL_BAD_DISPLAY error.

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

Removed flags and verified Linux build / execution still works properly.

Change-Id: Ibad4ec5d1b89d8e9b826c57bf2d6dbd0d18b7a2e
Reviewed-on: https://swiftshader-review.googlesource.com/9812Reviewed-by: Nico Weber <thakis@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Bug swiftshader:53

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

Bug swiftshader:52

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

In OpenGL ES 3.0, varyings declared in the vertex shader may be
used by transform feedback, regardless of whether or not they are
also declared in the fragment shader. In OpenGL ES 2.0, these
unmatched varyings are usually discarded. In order to preserve
the OpenGL ES 2.0 behavior and to not burden the Open GL ES 3.0
implementation with new unused varyings, only the unmatched
varyings which may be used as transform feedback inputs will be
added to the vertex shader, instead of always adding all of them.

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

Surface should not lock the resource of a parent texture at destruction, because
it can already have been destroyed. For example when a texture's image was bound
as a render target, and the texture is deleted by the app, then the image holds
the last reference to the texture. When the render target image gets deleted, it
first releases its parent texture, and then the underlying surface gets
destroyed.

This is fixed by synchronizing, by locking and unlocking the (parent) resource,
earlier. The derived class is responsible for calling Surface::sync() before
releasing the parent resource.

Bug chromium:716803

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

Bug b/37991302

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

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

Bug b/31651425

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

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>