Summary: | gallium/auxiliary/util/u_cpu_detect.c: 2 * bad condition ? | ||
---|---|---|---|
Product: | Mesa | Reporter: | dcb314 |
Component: | Mesa core | Assignee: | mesa-dev |
Status: | RESOLVED MOVED | QA Contact: | mesa-dev |
Severity: | normal | ||
Priority: | medium | ||
Version: | 17.2 | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
dcb314
2017-08-29 10:39:08 UTC
It would be helpful to add on which OS and with which compiler and for what architecture you were compiling mesa, because depending on the build environment xgetbv() may simply return 0 as a fallback (see lines 259-277 in the same file). (In reply to Gert Wollny from comment #1) > It would be helpful to add on which OS and with which compiler and for what > architecture you were compiling mesa, because depending on the build > environment xgetbv() may simply return 0 as a fallback (see lines 259-277 in > the same file). I think you missed the point. Any expression ANDed with 6 will be != 6. OS, compiler and arch independent. For the record, Linux, gcc and x86_64, although I used a static analyser called cppcheck to find this bug. (In reply to dcb314 from comment #2) > I think you missed the point. Any expression ANDed with 6 will be != 6. > How about when xgetbv() returns say 6 or 7 (amongst others)? Also keep in mind that the file depends on multiple defines. Based on a _very_ old play with Mesa + cppcheck, the latter was tripping quite often, producing false positives. The OS/compiler request does not sound that unreasonable ;-) -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1017. |
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.