Per the GLSL 1.20 specification (presumably a clarification of 1.10).
Also, when creating user functions, make a new ir_function that shadows the
built-in ir_function, rather than adding new signatures. User functions
are supposed to hide built-ins, not overload them.
Fixes piglit tests redeclaration-{04, 12, 14}.vert.
Moving the check for an earlier variable declaration helps cleanly
separate out the re-declaration vs. new declaration code a bit. With
that in place, conflicts between variable names and structure types or
function names aren't caught by the earlier "redeclaration" error
message, so check the return type on glsl_symbol_table::add_variable
and issue an error there. If one occurs, don't emit the initializer.
Fixes redeclaration-01.vert and redeclaration-09.vert.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
As of 1.20, variable names, function names, and structure type names all
share a single namespace, and should conflict with one another in the
same scope, or hide each other in nested scopes.
However, in 1.10, variables and functions can share the same name in the
same scope. Structure types, however, conflict with/hide both.
Fixes piglit tests redeclaration-06.vert, redeclaration-11.vert,
redeclaration-19.vert, and struct-05.vert.
We had ad-hoc handled some common cases by flagging sampler-typed
variables as read_only, and rejected initializers of samplers.
However, people could sneak them in in all sorts of surprising ways,
like using whole-array or structure assignment.
Fixes:
glslparsertest/glsl2/sampler-01.frag
glslparsertest/glsl2/sampler-03.frag
glslparsertest/glsl2/sampler-04.frag
glslparsertest/glsl2/sampler-06.frag
Bug #27403.
With MSVC it seems that this class and its constructor is colliding
with the one in ir_variable_refcount.cpp. Rename the class here to
avoid the collision.
This is a bit of a hack. Can the two variable_entry classes be merged
and shared?
A variable_entry after construction should have its referenced_count
member set to 0. However, occassionally this isn't the case and
entry->referenced_count has been observed to be a garbage value. This
leads to crashes of several tests in the Piglit test suite.
This patch adds an assert to check that a variable_entry instance has
its referenced_count member initialized to 0 after construction.
Because the static types talloc their names at dlopen time,
talloc_freeing the types at DRI driver screen teardown means that if
the screen gets brought back up again, the names will point at freed
memory. talloc_autofree_context() exists to do just what we want
here: Free memory referenced across the program's lifetime so that we
avoid noise in memory leak checkers.
Fixes: bug #29722 (assertion failure in unigine).
This prevents assertion failures or cascading errors after we've
logged the fact that we were unable to handle the initializer.
Fixes unsized-array-non-const-index-2.vert
The previous any() implementation would generate arg0.x || arg0.y ||
arg0.z. Having an expression operation for this makes it easy for the
backend to generate something easier (DPn + SNE for 915 FS, .any
predication on 965 VS)
Previously glcpp would silently abort if it couldn't fstat the file being
read, (so it would work with stdin redirected from a file, but would not
work with stdin as a tty). The stat was so that glcpp could allocate
a buffer for the file content in a single call.
We now use talloc_realloc instead, (even if the fstat is
possible). This is theoretically less efficient, but quite irrelevant,
(particularly because the standalone preprocessor is used only for
testing).
We recently added several tests that intentionally trigger
preprocessor errors. During valgrind-based testing, our test script
was noticing the non-zero return value from the preprocessor and
incorrectly flagging the valgrind-based test as failing.
To fix this, we make valgrind return an error code that is otherwise
unused by the preprocessor.
This error message was missing so that the program would simply
segfault if the provided filename could not be opened for some reason.
While we're at it, we add explicit support for a filename of "-" to
indicate input from stdin.
The existing DECIMAL_INTEGER pattern is the correct thing to use when
looking for a C decimal integer, (that is, a digit-sequence not
starting with 0 which would instead be an octal integer).
But for #line, we really want to accept any digit sequence, (including
"0"), and always interpret it as a decimal constant. So we add a new
DIGITS pattern for this case.
This should fix the compilation failure noted in bug #28138https://bugs.freedesktop.org/show_bug.cgi?id=28138
(Though the generated file will not be updated until the next commit.)
Previously, the YY_USER_ACTION was overwriting the yylloc->source value
in every action, (after that value had been carefully set by the handling
of the #line directive). Instead, we want to initialize it once in
YY_USER_INIT and then not touch it at all in YY_USER_ACTION.
This test exposes two current bugs:
1. The source number is not being correctly emitted in error
messages (instead, it's always 0).
2. A directive of "#line 0" is resulting in the following
parse error:
preprocessor error: Invalid tokens after #
The README file had grown a little bit stale. We've been using newer
versions of both the GLSL and C99 specifications, so list those. Also,
several of the documented known limitations have since been fixed, so
remove those.
This directive is already implemented nicely, but wasn't previously tested.
It will be convenient to use this directive in further tests that rely
on error messages, (such as ensuring that #line correctly sets the line
number in the error message).
This should be mostly a noop, except that a plain dereference of a
variable that is not part of a constant expression could now get
"constant folded". I expect that for all current backends this will
be either a noop, or possibly a win when it provokes more
ir_algebraic. It'll also ensure that when new features are added,
tree walking will work normally. Before this, constants weren't
getting folded inside of loops.
I had used pkg-config from the Makefile because I didn't want to screw
around with the non-autoconf build, but that doesn't work because the
PKG_CONFIG_PATH or TALLOC_LIBS/TALLOC_CFLAGS that people set at
configure time needs to be respected and may not be present at build
time.
Bug #29585
i686-apple-darwin10-gcc-4.2.1 generated the following warning.
warning: 'score' may be used uninitialized in this function
GCC 4.4.3 on Linux didn't generate the above warning.
The 'vec4[12] foo' style already worked, but the 'vec4 foo[12]' style
did not. Also, 'vec4[] foo' was wrongly accepted.
Fixes piglit test cases array-19.vert and array-21.vert.
May fix fd.o bug #29684 (or at least part of it).
