Created attachment 48766 [details] output of glsl-autointconv(negative.function.ambiguousMatch) System Environment: -------------------------- Arch: i386 Platform: huronriver Libdrm: (master)2.4.26 Mesa: (master)a221807dc5d69598afd1d0e0a4e715fb82a9f30d Xserver: (master)xorg-server-1.10.2.902 Xf86_video_intel: (master)2.15.0-163-g98f2e3855d70c02b05e2721a70ebce0c17e44283 Kernel: (drm-intel-fixes)2b1ecb7337592a7bf0989efac46a5b52daab769e Bug detailed description: ------------------------- This regression happens on ironlake and sandybridge. Bisect find commit 60eb63a855cb89962f2d5bb91e238ff2d1ab8702 is the first bad commit. commit 60eb63a855cb89962f2d5bb91e238ff2d1ab8702 Author: Kenneth Graunke <kenneth@whitecape.org> AuthorDate: Tue Jun 14 16:28:32 2011 -0700 Commit: Kenneth Graunke <kenneth@whitecape.org> CommitDate: Wed Jun 29 16:07:13 2011 -0700 glsl: Find the "closest" signature when there are multiple matches. Previously, ir_function::matching_signature had a fatal bug: if a function had more than one non-exact match, it would simply return NULL. This occured, for example, when looking for max(uvec3, uvec3): - max(vec3, vec3) -> score 1 (found first) - max(ivec3, ivec3) -> score 1 (found second...used to return NULL here) - max(uvec3, uvec3) -> score 0 (exact match...the right answer) This did not occur for max(ivec3, ivec3) since the second match found was an exact match. The new behavior is to return a match with the lowest score. If there is an exact match, that will be returned. Otherwise, a match with the least number of implicit conversions is chosen. Fixes piglit tests max-uvec3.vert and glsl-inexact-overloads.shader_test. NOTE: This is a candidate for the 7.10 and 7.11 branches. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reproduce steps: ---------------- 1. xinit& 2. ./oglconform -z -s -suite all -v 2 -D 115 -test glsl-autointconv negative.function.ambiguousMatch
I'm curious to see which signature matched for the 3rd call to 'func'.
This regression only happens on mesa master branch.
@Ian: It matched the first one (which is what I expected my code to do). I implemented the wrong policy. Page 42 (49 of the PDF) prohibits ambiguous function calls (no exact match and multiple inexact matches). I've sent a patch to the mailing list for review which fixes the issue. Subject line is: [Mesa-dev] glsl: Reject ambiguous function calls (multiple inexact matches).
commit 7304909d6537e00252347a10d0bae54ffd77ff91 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Sat Jul 9 00:20:34 2011 -0700 glsl: Reject ambiguous function calls (multiple inexact matches). According to the GLSL 1.20 specification, "it is a semantic error if there are multiple ways to apply [implicit] conversions [...] such that the call can be made to match multiple signatures." Fixes a regression caused by 60eb63a855cb89962f2d5bb91e238ff2d1ab8702, which implemented the wrong policy of finding a "closest" match. However, this is not a revert, since the original code failed to continue looking for an exact match once it found two inexact matches. It's OK to have multiple inexact matches if there's also an exact match. NOTE: This is a candidate for the 7.10 and 7.11 branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38971 Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Verified with mesa master commit 02c8ee202f5a159659a027deae4721ff05cd1530.
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.