| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| common | ||
| compiler | ||
| libANGLE | ||
| libEGL | ||
| libGLESv2 | ||
| tests | ||
| third_party | ||
| angle.gyp | ||
| commit.h | ||
| commit_id.py | ||
| compiler.gypi | ||
| copy_compiler_dll.bat | ||
| libEGL.gypi | ||
| libGLESv2.gypi |
Parsing should accept all values between 0 and 0xFFFFFFFF as specified in ESSL 3.00 section 4.1.3. When a signed literal is parsed, it's interpreted as if it specifies the bit pattern of a two's complement integer. For example, parsing "0xFFFFFFFF" results in -1. Decimal literals behave the same way, so for example parsing "3000000000" results in -1294967296. This change affects parsing of literals in ESSL 1.00 as well. In ESSL 3.00, an out-of-range integer literal now generates a compiler error. Unit tests are added based on examples in the ESSL 3.00 spec and one example in GLSL 4.5 spec that ESSL should match. BUG=541550 TEST=angle_unittests Change-Id: I82f8ef5cfa2881019a3f80d77ff99707d61c000d Reviewed-on: https://chromium-review.googlesource.com/305420Reviewed-by:Zhenyao Mo <zmo@chromium.org> Tested-by:
Olli Etuaho <oetuaho@nvidia.com> Reviewed-by:
Corentin Wallez <cwallez@google.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| common | Loading commit data... | |
| compiler | Loading commit data... | |
| libANGLE | Loading commit data... | |
| libEGL | Loading commit data... | |
| libGLESv2 | Loading commit data... | |
| tests | Loading commit data... | |
| third_party | Loading commit data... | |
| angle.gyp | Loading commit data... | |
| commit.h | Loading commit data... | |
| commit_id.py | Loading commit data... | |
| compiler.gypi | Loading commit data... | |
| copy_compiler_dll.bat | Loading commit data... | |
| libEGL.gypi | Loading commit data... | |
| libGLESv2.gypi | Loading commit data... |