dEQP-GLES3.functional.shaders.preprocessor.builtin.line_and_file_expression_fragment.qpa: <Result StatusCode="Fail">expected shaders to compile and link properly, but failed to compile.</Result> dEQP-GLES3.functional.shaders.preprocessor.builtin.line_and_file_expression_vertex.qpa: <Result StatusCode="Fail">expected shaders to compile and link properly, but failed to compile.</Result> dEQP-GLES3.functional.shaders.preprocessor.builtin.line_expression_fragment.qpa: <Result StatusCode="Fail">expected shaders to compile and link properly, but failed to compile.</Result> dEQP-GLES3.functional.shaders.preprocessor.builtin.line_expression_vertex.qpa: <Result StatusCode="Fail">expected shaders to compile and link properly, but failed to compile.</Result> dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.defined_macro_defined_test_fragment.qpa: <Result StatusCode="Fail">expected shaders to compile and link properly, but failed to compile.</Result> dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.defined_macro_defined_test_vertex.qpa: <Result StatusCode="Fail">expected shaders to compile and link properly, but failed to compile.</Result>
Mesa git top commit: 389d6dedbe75defe07216ad761569a9b94f44e58 dEQP git top commit: ca988480be945772473f9256b6ae91fa6aa62bd1 Reproduced on HSW and SKL
Ugh. These are tests for that awful "arbitrary expressions in the #line directive" thing we discussed with Khronos, and no vendor actually wanted. We had planned to never support this, but apparently we either have to, or we have to go argue with Android people.
We'll have to argue with Android people then. We're never going to implement this garbage. Period.
It seems Mesa already supports such expressions for #define's, I wonder if same functionality could be hooked up to parse #line .. just a thought
(In reply to Tapani Pälli from comment #4) > It seems Mesa already supports such expressions for #define's, I wonder if > same functionality could be hooked up to parse #line .. just a thought oops this is not really true, following would need to be supported and is not currently supported "#line (233 +10) (+10)"
I've split out the define defined parts of this bug as: https://bugs.freedesktop.org/show_bug.cgi?id=98522 This bug will now just be about #line expressions.
(In reply to Kenneth Graunke from comment #6) > I've split out the define defined parts of this bug as: > https://bugs.freedesktop.org/show_bug.cgi?id=98522 > > This bug will now just be about #line expressions. since #line is very likely highly unused my proposal would be to handle these 'case by case', as example this branch contains patch that makes these particular cases pass: https://cgit.freedesktop.org/~tpalli/mesa/log/?h=handle_expr
Here's an updated version of that patch which passes the "line_expression" tests in addition to the "line_and_file_expression" tests. I haven't tested it further, and am not advocating one way or another...just making sure we have a hack in case someone needs them. https://cgit.freedesktop.org/~kwg/mesa/commit/?h=glcpp-line-expressions
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.