This will allow testing of disabled line-continuation on a case-by-case basis,
(with the option communicated to the preprocessor via the GL context).
---
src/glsl/glcpp/glcpp.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/src/gl
First we test that line continuations are honored within a comment, (as
recently changed in glcpp), then we test that line continuations can be
disabled via an option within the context. This is tested via the new support
for a test-specific command-line option passed to glcpp.
---
src/glsl/glcpp/
Previously, we were only supporting line-continuation backslash characters
within lines of pre-processor directives, (as per the specification). With
OpenGL 4.2 and GLES3, line continuations are now supported anywhere within a
shader.
While changing this, also fix a bug where the preprocessor was
This is to enable a quirk for Savage2 which includes a shader with a stray '\'
at the end of a comment line. Interpreting that backslash as a line
continuation will break the compilation of the shader, so we need a way to
disable this.
---
It is bogus that the new option is setup as something i965
As the preprocessor becomes more sophisticated and gains more optional
behavior, it's easiest to just pass the GL context pointer to it so that
it can examine any fields there that it needs to (such as API version,
or the state of any driconf options, etc.).
---
src/glsl/glcpp/glcpp.c |
And simply don't call into the function that removes line continuations.
---
src/glsl/glcpp/pp.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/glsl/glcpp/pp.c b/src/glsl/glcpp/pp.c
index 5f86a49..3f33648 100644
--- a/src/glsl/glcpp/pp.c
+++ b/src/glsl/glcpp/pp.c
@@
This application is known to contain shaders that:
1. Have a stray backslash as the last line of comment lines
2. Have a declaration immediately following that line
Hence, interpreting that backslash as a line continuation causes the
declaration to be hidden and the shader fails to compile. Fort
This will allow the test exercising disabled line continuations to arrange
for the --disable-line-continuations argument to be passed to the standalone
glcpp.
---
src/glsl/glcpp/tests/glcpp-test | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glcpp/tests/
Chad Versace writes:
> Taking the Android.mk's out of Mesa without replacing them with an
> Androgenizer-like tool would impose that insufferable situation on
> the Android developers.
I certainly wasn't proposing that.
What I would like to do is to eliminate as much of the duplicated
informatio
Ian Romanick writes:
> On 12/03/2012 03:43 PM, Carl Worth wrote:
>> This strangely-escaped apostrophe was causing a build failure
>> ("invalid escape sequence") resulting in no "de" translations in the
>> final options.h file.
>
> It seems like this
As can be seen, many other translation strings already include a single
apostrophe just fine without any escaping. This strangely-escaped apostrophe
was causing a build failure ("invalid escape sequence") resulting in no "de"
translations in the final options.h file.
---
src/mesa/drivers/dri/commo
So that there's some chance that "make options.h" can even work.
---
0 files changed
mode change 100644 => 100755 src/mesa/drivers/dri/common/xmlpool/gen_xmlpool.py
diff --git a/src/mesa/drivers/dri/common/xmlpool/gen_xmlpool.py
b/src/mesa/drivers/dri/common/xmlpool/gen_xmlpool.py
old mode 1006
These translations have existed in the de.po file, but were not in the
generated options.h file. This was fixed by simply running "make options.h".
---
src/mesa/drivers/dri/common/xmlpool/options.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/mesa/driv
For the last two most-recently-added driconf options, their definition was
manually added to options.h, a file which is intended to be automatically
generated, (as part of support for translated driconf option
descriptions). This means that these options would be eliminated if the
generation step w
Kenneth Graunke writes:
> I'm pretty tempted by ralloc_rewrite_tail & ralloc_strn_rewrite_tail.
I still don't like the lack of symmetry here. Maybe bite the bullet and
make the first one ralloc_str_rewrite_tail?
But that "rewrite_tail" keeps feeling so awkward. I think the real
problem is that i
Kenneth Graunke writes:
> Other than than, looks good to me...thanks Carl!
>
> Reviewed-by: Kenneth Graunke
Thanks, Ken. Pushed now.
> Someday we may want to use ralloc's rewrite_tail functions to avoid the
> extra strlen() overhead. But that can be done separately.
I took a look at this now
Ian Romanick writes:
> I have also pushed this branch to the gles3 branch of my personal GIT
> repo on fd.o. Could people working on the gles3 branch take a look to
> make sure no work got lost? I'd like to force-push this to origin/gles3
> today.
I haven't reviewed every change on the branc
Such as:
#line 23 "foo.c"
Having a filename here is quite useful and many other OpenGL implementations
allow this.
Note that for GLES we take the hard line and insist on a numeric source string
number as per the specification and which glcpp has always supported:
#line 23 3
---
Previously, we were only supporting line-continuation backslash characters
within lines of pre-processor directives, (as per the specification). With
OpenGL 4.3, line continuations are now supported anywhere within a shader.
While changing this, also fix a bug where the preprocessor was ignoring l
Matt Turner writes:
> #line __LINE__
> __LINE__
> #line __LINE__
> __LINE__
>
> when run through glcpp emits this:
>
> #line 1
> 1
> #line 2
> 2
That looks absolutely correct to me, (if very strange to ever do "#line
__LINE__"). For example, this matches the behavior of "gcc -E -" on the
same exa
Drop these from the known limitations list since support was recently added
for these.
Also, fix a typo while in the area, (and the oddly missing final newline).
---
src/glsl/glcpp/README |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/glsl/glcpp/README b/src/glsl/gl
Matt Turner writes:
> "##" {
> + if (parser->is_gles)
> + glcpp_error(yylloc, yyextra, "Token pasting (##) is illegal in
> GLES");
> return PASTE;
I'm glad that is_gles flag is proving useful. Thanks for doing this one.
Rev
This test file is very similar to test 113-line-and-file-macros but
uses token pasting for cleaner quiz answers (without spaces between
the digits). This test happens to fail currently because the token
paster does not support the pasting of INTEGER tokens.
(Note that this test is distinct from te
By generalizing the current code designed to paste string tokens of various
types. With this commit, the recently added 114-paste-integer-tokens test now
passes.
---
src/glsl/glcpp/glcpp-parse.y | 61 --
1 file changed, 47 insertions(+), 14 deletions(-)
d
As recently tested in the additions to the invalid paste test, it is illegal
to paste a non-digit sequence onto the end of an integer.
The 082-invalid-paste test should now pass again.
---
src/glsl/glcpp/glcpp-parse.y | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
di
This time creating a new _token_list_create_with_one_integer function
modeled after the existing _token_list_create_with_one_space function
(both implemented with new _token_list_create_with_one_ival).
---
src/glsl/glcpp/glcpp-parse.y | 46 ++
1 file chang
The current code lets a few invalid pastes through, such as an string pasted
onto the end of an integer. Extend the invalid-paste test to catch some of
these.
---
src/glsl/glcpp/tests/082-invalid-paste.c |5 +
src/glsl/glcpp/tests/082-invalid-paste.c.expected | 15 ++
This function is getting a little long too read. Simplify it by pulling
up one assignment from every condition.
---
src/glsl/glcpp/glcpp-parse.y |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index d928044..5b3
These tokens are easy to expand by just looking at the current, tracked
location values, (and no need to look anything up in the hash table).
Add a test which verifies __LINE__ with several values, (and verifies __FILE__
for the single value of 0). Our testing framework isn't so[hissticated enough
Carl Worth writes:
> (For the subsequent __LINE__ and __FILE__ I think we can do better, and
> I'll attempt that next.)
I've coded this up, and I think the support is quite reasonable.
After I coded it, I simplified some repeated code a bit, and then I
started exploring some to
Matt Turner writes:
> Here's the write-up of what I was seeing earlier today for my own record.
>
> #if 1
> #elif
> #endif
>
> gives "0:2(1): preprocessor warning: ignoring illegal #elif without
> expression". gcc rejects it, but glcpp just warns since #if is true
> and it doesn't need to evaluate
ut the
only test case is in the negative sense, (flagging an invalid identifier
of elif110 after the '#'). I'd like to also see a passing test with
something like:
#if 0
#elif(1)
success
#endif
With that added, I give:
Reviewed-by: Carl Worth
to this commit and the preceding co
Ian Romanick writes:
> On 11/26/2012 03:12 PM, Carl Worth wrote:
> I assume this makes the piglit test pass? That should be mentioned in
> the commit message.
Yes. I've added that to the commit message now.
> Assuming that's the case, the series is
>
> Reviewed-by:
Simply emitting a nicely-formatted error message if any undefined macro is
encoutnered in a parser context expecting an expression.
---
src/glsl/glcpp/glcpp-parse.y |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index 258eb6e..b
On 2012-11-26, Ian Romanick wrote:
> There isn't one. We treat OpenGL ES 3 as version 30 of API_OPENGLES2.
> There's a utility function _mesa_is_gles3 to check this. See
> src/mesa/main/context.h.
Thanks for the tip.
As a follow-up to this mail I'm sending two new patches with my
radically si
This can be triggered either by creation of a GLES context (with
api == API_OPENGLES2) or else by a #version directive with version
value 100 or with a string of "es" following the version value.
---
src/glsl/glcpp/glcpp-parse.y | 26 +++---
src/glsl/glcpp/glcpp.h |
Carl Worth writes:
> With this change, there's no (intended) behavioral change. The
> undefined_macro_mode flag is set to UNDEFINED_MACRO_IS_ZERO only when
> expanding an #if or #elif expression. All other expansions will leave the
> undefined macro as an identifier.
I'm g
Previously, the grammar would cause any identifier parsed in a context
expecting an expression to yield an integer value of zero. A future change
will make this behavior conditional, (depending on the GL API). In order to
enable that, we move the macro->0 conversion from the grammar to explicit cod
The specification is clear that an undefined macro in an #if or #elif should
cause an error. This is distinct from the behavior required for recent desktop
OpenGL.
FIXME: This commit isn't compiling for me since I don't have any API_OPENGLES3
symbol in my environment. I'm seeking guidance on how t
Here are a couple of patches to implement the desired behavior for Ian's
recently-proposed undefined-macro.vert test, (where "#if undefined_macro"
should cause an error for GLES3).
The first patch lays the groundwork for the new, conditional treatment of
undefined macros. This commit should be rea
neth Graunke
Also:
Reviewed-by: Carl Worth
-Carl
pgpXT3lMxBrKI.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Kenneth Graunke writes:
> Fixes piglit test 17000-consecutive-chars-identifier.frag.
Thanks for fixing this. It will be nice to have this long-standing bug
finally addressed.
Reviewed-by: Carl Worth
-Carl
pgpO8dqDxs6Gd.pgp
Description: PGP signat
Kenneth Graunke writes:
> Sorry for the extremely late review. (Lost this one in the inbox.)
No problem at all.
> Could yylineno and yylloc->source be set directly from the rules, rather
> than using flags and setting them here? It seems like they could, but I
> imagine you tried that and it d
This function is currently used only in the expansion of #if lines,
but we will soon be using it more generally (for the expansion of
(_glcpp_parser_expand_and_lex_from) and some more documentation.
---
> What I'd like to see is the preprocessor interpreting the #line
> directives (for its own not
The most recent commit adds support for comments and macro expansion
on #line directives. Add testing to verify the new features.
---
src/glsl/glcpp/tests/091-hash-line.c |6 ++
src/glsl/glcpp/tests/091-hash-line.c.expected |6 ++
2 files changed, 12 insertions(+)
diff --
The GLSL specification requires that #line directives be interpreted
after macro expansion. Our existing implementation of #line macros in
the lexer prevents conformance on this point.
Moving the handling of #line from the lexer to the parser gives us the
macro expansion we need. An additional ben
Kenneth Graunke writes:
> One bad thing about this patch is that it breaks 091-hash-line.c in glcpp's
> unit test suite. I'm not sure what to do about that. I could update the
> output, but the new output doesn't make much sense anymore...it gives you
> lovely messages like:
>
> 0:4(1): prep
Commit b823b99ec0f13af257dcd885f436a4d294c6222a switched from using
functions such as ralloc_asprintf and ralloc_strcat to
ralloc_asprintf_rewrite_tail. This change maintains the string's
length as a aparamter that is updated by the ralloc functions (rather
than recomputing it with strlen over and
A strict reading of the GLSL specification would have this be an
error, but we've received reports from users who expect the
preprocessor to interepret undefined macros as 0. This is the standard
behavior of the rpeprocessor for C, and according to these user
reports is also the behavior of other O
Kenneth Graunke writes:
> One bad thing about this patch is that it breaks 091-hash-line.c in glcpp's
> unit test suite. I'm not sure what to do about that. I could update the
> output, but the new output doesn't make much sense anymore...it gives you
> lovely messages like:
>
> 0:4(1): prep
On Fri, 13 Apr 2012 11:04:16 -0700, Ian Romanick wrote:
> As a side comment, we should probably get the glcpp unit tests wired
> into 'make check'.
This did happen at one point.
Oh, but was that removed again as part of de-automake-ification perhaps?
I totally agree it would be very useful to
On 2012-02-04, Jon TURNEY wrote:
> It looks like these error messages will always be emitted when software-direct
> and indirect are the only paths available (e.g. when ./configured with
> --with-dri-drivers=swrast or --disable-driglx-direct).
Thanks for sharing your concern, Jon. I certainly don'
Something has gone wrong if we were asked to load a driver of a
specific name, but it failed to load for some reason. The user really
should be made aware of this, (and instructed to set LIBGL_DEBUG for
more details).
---
src/glx/dri2_glx.c |2 ++
src/glx/dri_glx.c |2 ++
2 files changed,
Something has gone wrong if swrast is requested but cannot be
loaded. The user really should be made aware of this, (and instructed
to set LIBGL_DEBUG for more details).
The wording of this error message is updated from "reverting to
indirect rendering" to the more objectively descriptive "failed
Something has gone wrong if we have to revert to software rendering.
The user really should be made aware of this, (and instructed to set
LIBGL_DEBUG for more details).
---
src/glx/dri_glx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glx/dri_glx.c b/src/glx/dri_g
The description of ErrorMessageF was misleading in the case of
LIBGL_DEBUG being unset, (the previous comment could be understood to
mean the error should be printed, but the code does not print in this
case).
InfoMessageF previously had no comment at all.
---
src/glx/dri_common.c |7 ++-
Sometimes an error is so sever that we want to print it even when the
user hasn't specifically requested debugging by setting LIBGL_DEBUG.
Add a CriticalErrorMessageF macro to be used for this case. (The error
message can still be slienced with the existing LIBGL_DEBUG=quiet).
For critical error
Something has gone wrong if we have to revert to indirect rendering,
(such as a driver failing to load for some reason). The user really
should be made aware of this, (and instructed to set LIBGL_DEBUG
for more details).
---
src/glx/drisw_glx.c |2 +-
1 files changed, 1 insertions(+), 1 deleti
I recently had a problem with a dri driver failing to load, (it turned
out to be a case of the driver being built for 64-bit, but running a
32-bit application).
At the time, mesa switched over to indirect rendering without me
realizing it at all. This left me quite confused. Finally, a kind
friend
Since talloc has more debugging features than ralloc, such as the
very useful:
talloc_report_full(ctx, stdout);
we here conditionally implement ralloc by simply calling directly into
talloc.
NOTE: This commit is simply example code that I used recently, and I
thought I should share in c
On Sat, 21 Jan 2012 10:53:20 -0800, Ian Romanick wrote:
> The fix seems correct, but reading that regex made my head hurt.
Thanks. And, yes, it was pretty bad before, and the copying made it much
worse.
> Is there a way to refactor the character classes to be more readable?
> OTHER is basically
Here's a real-quick patch series to fix the bug mentioned here:
GLSL preprocessor doesn't replace defines ending with ":"
https://bugs.freedesktop.org/show_bug.cgi?id=44764
I believe the patch is correct, but I haven't run any testing more
than the set of ~100 glcpp tests. [My pig
This demonstrates a bug that was recently triggered in piglit.
Here is the original bug report (containing a test case almost identical
to this one):
https://bugs.freedesktop.org/show_bug.cgi?id=44764
---
src/glsl/glcpp/tests/100-macro-with-colon.c|7 +++
.../glcpp/tests/
The trick here is that flex always chooses the rule that matches the most
text. So with a input text of "two:" which we want to be lexed as an
IDENTIFIER token "two" followed by an OTHER token ":" the previous OTHER
rule would match longer as a single token of "two:" which we don't want.
We preven
On Fri, 30 Sep 2011 12:32:13 -0700, Ian Romanick wrote:
> > In any case, the test quotes specific language from the GLSL spec that
> > explicitly forbids this behavior, so I'm somewhat reluctant to deviate
> > from the spec'ed behavior.
We're not deviating from what is specified.
We do raise an
On Thu, 29 Sep 2011 23:43:49 -0700, Kenneth Graunke
wrote:
> For the series:
> Reviewed-by: Kenneth Graunke
>
> Thanks for fixing these, Carl!
No problem. Thanks to you (and Eric) for the review.
> > I'll be glad to push changes to piglit to fix these cases unless
> > someone can argue aginst
The specification reserves any macro name containing two consecutive
underscores, (anywhere within the name). Previously, we only raised
this error for macro names that started with two underscores.
Fix the implementation to check for two underscores anywhere, and also
update the corresponding 086
As written, this test correctly raises an error for #elif being used
with an undefined macro (and not as an argument to "defined"). If the
preceding #if were '#if 1' then this diagnositc would correctly be
hidden. That allows code such as the following to not raise an error:
#ifndef MAYBE_
This is something that piglit is exercising that currently fails.
---
src/glsl/glcpp/tests/096-paste-twice.c |3 +++
src/glsl/glcpp/tests/096-paste-twice.c.expected |4
2 files changed, 7 insertions(+), 0 deletions(-)
create mode 100644 src/glsl/glcpp/tests/096-paste-twice.c
There was already a loop here to look for multiple token pastes, but
it was mistakenly incrementing the iterator counter after performing
one paste.
Instead, leave the loop iterator in place to coalesce as many tokens
as necessary into one.
This fixes the recently add 096-paste-twice test as well
Eric recentl mentioned to me that when setting the following
environment variables with current master mesa:
MESA_GL_VERSION_OVERRIDE=3.0
MESA_GLSL_VERSION_OVERRIDE=130
that 8 piglit preprocessor tests start to fail.
I've investigated all of these failures and am here attaching a
Apparently we never implemented this, (but we've got a GLSL 1.30 test
in piglit that is exercising this case).
---
.../tests/097-paste-with-non-function-macro.c |3 +++
.../097-paste-with-non-function-macro.c.expected |4
2 files changed, 7 insertions(+), 0 deletions(-)
create
This is as simple as abstracting one existing block of code into a
function call and then adding a single call to that function for the
case of a non-function-like macro.
This fixes the recently-added 097-paste-with-non-function-macro test
as well as the following piglit tests:
spec/glsl-
The 095-recursive-define test case was triggering infinite recursion
with the following test case:
#define A(a, b) B(a, b)
#define C A(0, C)
C
Here's what as happening:
1. "C" was pushed onto the active list to expand the C node
2. While expanding the "0" argument, t
On Fri, 28 Jan 2011 08:42:23 -0800, Ian Romanick wrote:
> Given the date on this commit, I'm going to assume that you pushed this
> by mistake. We decided months ago that this test case was just plain
> wrong, and we removed it from the test list. Could you please revert
> this commit?
Ah, that
On Mon, 06 Dec 2010 20:23:52 +, José Fonseca wrote:
> I suppose it is possible for space to be significant on a conditional
> expression, e.g.,
>
> #if foo ()
>
> vs
>
> #if foo
There's no significant whitespace here. A function-like macro can be
invoked without or without intervening
On Fri, 3 Dec 2010 13:34:09 -0800, Kenneth Graunke
wrote:
> On Friday 03 December 2010 08:01:06 José Fonseca wrote:
> > parser->space_tokens = 1;
> >
> > statement conditional_tokens stanza -- it causes space tokens to be
> > emitted halfway before reaching the DEFINED token.
>
> Indeed. I'm
401 - 477 of 477 matches
Mail list logo
