There is no explicit predefined macro to distinguish between OpenSolaris
and Solaris. This patch assumes that the difference is in the compilers.
OpenSolaris uses GCC and not the Sun Studio compiler. Assume that the
availability of fpclassify is due to GCC.
This patch was not tested on Solaris. It would break the build on
Solaris with GCC if GCC on Solaris does not have fpclassify.
This should make it easier to diff the output, clean up some of the
insane whitespace, and make the strings a bit smaller.
We'll probably need to split up the prototype strings eventually, but
for now, this gets it under the 65K mark.
Calls to equal(bvec, bvec) or notEqual(bvec, bvec) previously caused an
assertion. Fixes piglit tests glsl-const-builtin-equal-bool and
glsl-const-builtin-notEqual-bool.
Carefully avoiding printing any error when the new definition matches
the existing definition.
This fixes the recently-added 088-redefine-macro-legitimate.c and
089-redefine-macro-error.c tests as well as glsparsertest/preprocess1
in piglit.
The specification says that redefining a macro is an error, unless the
new definitions is identical to the old one, (identical replacement
lists but ignoring differing amounts of whitespace).
In commit 6be3a8b70a, the #version directive
was fixed to stop generating a spurious newline. Here we simply update
the expected result for the single test which includes a #version directive.
Matching the newline here meant having to do some redundant work here,
(incrementing line number, resetting column number, and returning a
NEWLINE token), that could otherwise simply be left to the existing rule
which matches a newline.
Worse, when the comment rule matches the newline as well, the parser
can lookahead and see a token for something that should actually be skipped.
For example, in a case like this:
#if 0 // comment here
fail
#else
win
#endif
Both fail and win appear in the output, (not that the condition is being
evaluated incorrectly---merely that one token after the comment's newline
was being lexed/parse regardless of the condition).
This commit fixes the above test case, (which is also remarkably similar
to 087-if-comments which now passes).
I didn't expect that this would really work, but it turns out there
are shaders in the wild that do it.
Fixes: (with swrast)
glsl-fs-main-return
glsl-vs-main-return
These binops are the vector-to-bool comparisons, not vec-to-bvec. We
likely want both operations avilable as expression, since 915 and 965
FS naturally does the vector version, while 965 VS can also naturally
do the scalar version. However, we can save that until later.
Fixes:
glsl-fs-vec4-operator-equal.shader_test
glsl-fs-vec4-operator-notequal.shader_test
glsl-vs-vec4-operator-equal.shader_test
glsl-vs-vec4-operator-notequal.shader_test
Now that we have glsl2 with if flattening in place, most shaders will
just work. Remaining failing shaders will mostly be due to loop
unrolling (in progress), some possible if flattening failures in
inlining functions (planning on fixing), and the register/instruction
count limits.
While the GLSL and GLSL-ES specs say that shaders shouldn't fail to
compile/link due to register/instruction limits, in practice we're not
the first vendor to expose GLSL on hardware with these limitations.
The benefit to application developers of providing a better language
for GPU programming is greater than the pain of having to handle
instruction limits (which they had to for ARB_fp on this hardware
anyway)
This error led to an assertion failure for some constructors of
non-square matrices. It only occured in matrices where the number of
columns was greater than the number of rows. It didn't even always
occur on those.
Fixes piglit glslparsertest case constructor-16.vert.
