Summary: | glslparsertest: ir.cpp:358: ir_constant::ir_constant(const glsl_type*, const ir_constant_data*): Assertion `(type->base_type >= 0) && (type->base_type <= 3)' failed. | ||
---|---|---|---|
Product: | Mesa | Reporter: | Vinson Lee <vlee> |
Component: | Mesa core | Assignee: | Chad Versace <chadversary> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | medium | CC: | brianp, idr, kenneth |
Version: | git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | Fix for bug. |
Description
Vinson Lee
2010-11-03 19:54:22 UTC
git bisect good 4af293741635aea8630e8734a8b4caf58047e91d git bisect bad 16333e1fc489a414233bc485f1230b847d11b020 cfdbf8bc8497b29fbdd9fa7bd00da554aecb5962 is the first bad commit commit cfdbf8bc8497b29fbdd9fa7bd00da554aecb5962 Author: Chad Versace <chad.versace@intel.com> Date: Fri Oct 15 11:28:05 2010 -0700 glsl: Define bit_logic_result_type() in ast_to_hir.cpp This function type checks the operands of and returns the result type of bit-logic operations. It replaces the type checking performed in the following cases of ast_expression::hir() : - ast_bit_and - ast_bit_or - ast_bit_xor :040000 040000 00d9f41690488d71e665e7e8008df051eee45d24 d4b4be0baaa01eb4783af67fa94272bc266bda9f M src bisect run success My preprocess6 branch (in ~kwg/mesa) fixes this assertion failure, but may be just papering over the problem. Looking into why/how error_type values are getting mishandled in ast_to_hir is probably valuable. It may reveal a better fix. I'm confused as to why this passes on llvmpipe but asserts on other software drivers. At the point of the assertion, nothing device dependent should have come into play. What does the test do on a hardware driver? (In reply to comment #3) > My preprocess6 branch (in ~kwg/mesa) fixes this assertion failure, but may be > just papering over the problem. > > Looking into why/how error_type values are getting mishandled in ast_to_hir is > probably valuable. It may reveal a better fix. I don't think treating error expressions as some sort of odd constant error is right. Shouldn't ir_expression::constant_expression_value just return NULL if the type is error? That seems like a more correct fix (assuming that fixes it). Created attachment 40130 [details] [review] Fix for bug. (In reply to comment #4) > I don't think treating error expressions as some sort of odd constant error is > right. Shouldn't ir_expression::constant_expression_value just return NULL if > the type is error? That seems like a more correct fix (assuming that fixes > it). I just submitted a 3-line patch that does exactly that. And it does fix the bug, at least on i915 and swrast. (Sorry for the double-post.) Ah man, I was way overthinking things. That's definitely a sensible solution. Confirmed fixed and pushed to master (with minor fix - 3-space indentation rather than 4). Thanks Chad and Ian. commit b62c1c4595551c4936323135224a5ea686ba972a Author: Chad Versace <chad.versace@intel.com> Date: Mon Nov 8 17:30:13 2010 -0800 glsl: Fix ir_expression::constant_expression_value() When the type of the ir_expression is error_type, return NULL. This fixes bug 31371. mesa: dc524adee2cfd0f115800cd4ec3f8384010f154e (master) Verified fixed on swrast, softpipe, and llvmpipe. |
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.