glsl: support unsigned increment in ir_loop controls

Current version can create ir_expression where operands have
different base type, patch adds support for unsigned type.

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
https://bugs.freedesktop.org/show_bug.cgi?id=80880
i965/clip: Fix brw_clip_unfilled.c/compute_offset's assembly.

Due to the destination register width of 1 or 2, these instructions get
ExecSize 1 or 2.  But dir and offset (used as src0) are both registers
of width 4, violating the execsize >= width assertion.

I honestly don't think this could have ever worked.

Fixes Piglit's polygon-offset and polygon-mode-offset tests on Gen4-5.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70441
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
glsl_to_tgsi: Constify mesa_sysval_to_semantic

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
mesa/st: Only one copy of mesa_sysval_to_semantic

Future patches will necessitate changes to the table, and I only want to
update one.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
glsl_to_tgsi: Assert that the _mesa_sysval_to_semantic mapping is correct

Future patches will rearrange the values in gl_system_value, and I want
to catch errors.  Designated initializers would make all of this
unnecessary.

v2: Don't use STATIC_ASSERT.  Not only does it not work, but GCC doesn't
tell you that it's not going to work.  Thanks for nothing!

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
mesa: Group gl_system_value values by the stage where they exist

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
mesa: Drop USE_IEEE define.

I think OpenVMS was the only platform that Mesa ran on that used a
non-IEEE representation for floats. We removed OpenVMS support a while
back, and this should alleviate the need to continue updating the
this-platform-uses-IEEE list.

The one bit of this patch that needs review is the IS_INF_OR_NAN,
because I'm not sure if MSVC supports isfinite.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82268
Reviewed-by: Brian Paul <brianp@vmware.com>
i965/vec4: Remove unused emit_bool_comparison method.

Apparently unused since it was added in commit af3c9803.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
docs: List GL+GLSL versions as parts of a whole.

Listing the GLSL version as an individual component of a GL version,
separate from the extensions isn't really right. The GLSL changes are
(almost?) entirely comprised of changes listed in the extensions.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
glsl/glcpp: Add explicit error for "#define without macro name"

Previously, glcpp would emit an error like this if <EOF> happened to occur
immediately after the "#define", but in general would just get confused,
(leading to un-helpful error messages).

To fix things to generate a clean error message, we do a few things:

	1. Don't require horizontal whitespace immediately after #define

	2. Add a production for the error case, (DEFINE_TOKEN followed
	   immediately by a NEWLINE token).

	3. Make the lexer reset to the <INITIAL> state after every NEWLINE.

This 3rd point prevents the lexer from getting so confused and generating
further spurious errors in the file because it was stuck in the <DEFINE> start
condition.

We also drop the similar error message from the <EOF> rule since the
newly-added rule will have already printed the error message.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/glcpp: Add test for "#define without macro name"

This ensures that the previous commit indeed generates the expected error
message when a "#define" directive is not followed by anything except for a
newline.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/glcpp: Allow single-line comments immediately after #define

We were already correctly supporting single-line comments in case like:

	#define FOO bar // comment here...

The new support added here is simply for the none-too-useful:

	#define // comment instead of macro name

With this commit, this line will now give the expected "#define without
macro name" error message instead of the lexer just going off into the
weeds.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/glcpp: Add tests for #define followed by comments

This simply tests the previous commit, (that #define followed by a comment
will still generate the expected "#define without macro name" error message).

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/glcpp: Fix NULL directives when followed by a single-line comment

This is the fix for the following line:

	#  // comment to ignore here

According to the translation-phase rules, the comment should be removed before
the preprocessor looks to interpret the null directive.

So in our implementation we must explicitly look for single-line comments in
the <HASH> start condition as well.

This commit fixes the following Khronos GLES3 CTS tests:

	null_directive_vertex
	null_directive_fragment

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/glcpp: Add testing for null directives with spaces and comments

This new "make check" test stresses out the support from the last two commits,
(to esnure that '#' is correctly interpreted as the null directives,
regardless of any whitespace or comments on the same line).

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/glcpp: Fix #pragma to not over-increment the line-number count

Previously, the #pragma directive was swallowing an entire line, (including
the final newline). At that time it was appropriate for it to increment the
line count.

More recently, our handling of #pragma changed to not include the newline. But
the code to increment yylineno stuck around. This was causing __LINE__ to be
increased by one more than desired for every #pragma.

Remove the bogus, extra increment, and add a test for this case.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/glcpp: Swallow empty #pragma directives.

Previously, we were passing these through, just like any other pragma. But the
downstream compiler was tripping up on them. It seems easier to swallow these
in the preprocessor and not pass them on at all rather than fixing the
downstream compiler.

This fixes the following Khronos GLES3 CTS tests:

	preprocessor.pragmas.pragma_vertex
	preprocessor.pragmas.pragma_fragment

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/glcpp: Fix for macros that expand to include "defined" operators

Prior to this commit, the following snippet would trigger an error in glcpp:

	#define FOO defined BAR
	#if FOO
        #endif

The problem was that support for the "defined" operator was implemented within
the grammar, (where the parser was parsing the tokens of the condition
itself). But what is required is to interpret the "defined" operator that
results after macro expansion is performed.

I could not find any fix for this case by modifying the grammar alone. The
difficulty is that outside of the grammar we already have a recursive function
that performs macro expansion (_glcpp_parser_expand_token_list) and that
function itself must be augmented to be made aware of the semantics of the
"defined" operator.

The reason we can't simply handle "defined" outside of the recursive expansion
function is that not only must we scan for any "defined" operators in the
original condition (before any macro expansion occurs); but at each level of
the recursive expansion, we must again scan the list of tokens resulting from
expansion and handle "defined" before entering the next level of recursion to
further expand macros.

And of course, all of this is context dependent. The evaluation of "defined"
operators must only happen when we are handling preprocessor conditionals,
(#if and #elif) and not when performing any other expansion, (such as in the
main body).

To implement this, we add a new "mode" parameter to all of the expansion
functions to specify whether resulting DEFINED tokens should be evaluated or
ignored.

One side benefit of this change is that an ugly wart in the grammar is
removed. We previously had "conditional_token" and "conditional_tokens"
productions that were basically copies of "pp_token" and "pp_tokens" but with
added productions for the various forms of DEFINED operators. With the new
code here, those ugly copy-and-paste productions are eliminated from the
grammar.

A new "make check" test is added to stress-test the code here.

This commit fixes the following Khronos GLES3 CTS tests:

	conditional_inclusion.basic_2_vertex
	conditional_inclusion.basic_2_fragment

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/glcpp: Add test script for testing various line-termination characters

The GLSL specification has a very broad definition of what is a
newline. Namely, it can be the carriage-return character, '\r', the newline
character, '\n', or any combination of the two, (though in combination, the
two are treated as a single newline).

Here, we add a new test-runner, glcpp-test-cr-lf, that, for each possible
line-termination combination, runs through the existing test suite with all
source files modified to use those line-termination characters. Instead of
using the .expected files for this, this script assumes that the regular test
suite has been run already and expects the output to match the .out
files. This avoids getting 4 test failures for any one bug, and instead will
hopefully only report bugs actually related to the line-termination
characters.

The new testing is not yet integrated into "make check". For that, some
munging of the testdir option will be necessary, (to support "make check" with
out-of-tree builds). For now, the scripts can just be run directly by hand.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/glcpp: Treat CR+LF pair as a single newline

The GLSL specification says that either carriage-return, line-feed, or both
together can be used to terminate lines. Further, it says that when used
together, the pair of terminators shall be interpreted as a single line.

This final requirement has not been respected by glcpp up until now, (it has
been emitting two newlines for every CR+LF pair).

Here, we fix the lexer by using a regular expression for NEWLINE that eats
up both "\r\n" (or even "\n\r") if possible before also considering a single
'\n' or a single '\r' as a line terminator.

Before this commit, the test results are as follows:

	\r:	135/143 tests pass
	\r\n:	  4/143 tests pass
	\n\r:	  4/143 tests pass

After this commit, the test results are as follows:

	\r:	135/143 tests pass
	\r\n:	140/143 tests pass
	\n\r:	139/143 tests pass

So, obviously, a dramatic improvement.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>