https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42361 From e261dd933d7fa4730540ca5275241b46827bcd0b Mon Sep 17 00:00:00 2001 From: Sam James Date: Sun, 21 Jun 2026 04:53:41 +0100 Subject: [PATCH] util: remove bogus const attribute With GCC trunk (observed at r17-1670-g7374385c962b86), I saw a SIGFPE in llvmpipe_init_compute_caps because lp_native_vector_width was 0. This turns out to be because util_get_cpu_caps is marked with ATTRIBUTE_CONST which imposes strong requirements [0]. In particular: > The const attribute prohibits a function from reading objects that affect its > return value between successive invocations. [0] https://gcc.gnu.org/onlinedocs/gcc/Common-Attributes.html#index-const Bug: https://gcc.gnu.org/PR125916 Fixes: 1b8a43a0baf ("util: Remove util_cpu_detect") Signed-off-by: Sam James --- src/util/u_cpu_detect.h | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/src/util/u_cpu_detect.h b/src/util/u_cpu_detect.h index 214c0115fe30..a4f47f69b4b9 100644 --- a/src/util/u_cpu_detect.h +++ b/src/util/u_cpu_detect.h @@ -143,7 +143,7 @@ struct _util_cpu_caps_state_t { #define U_CPU_INVALID_L3 0xffff -static inline ATTRIBUTE_CONST const struct util_cpu_caps_t * +static inline const struct util_cpu_caps_t * util_get_cpu_caps(void) { extern void _util_cpu_detect_once(void); @@ -153,24 +153,6 @@ util_get_cpu_caps(void) * load instruction with some extra compiler magic to prevent code * re-ordering around it. The perf impact of doing this check should be * negligible in most cases. - * - * Also, even though it looks like a bit of a lie, we've declared this - * function with ATTRIBUTE_CONST. The GCC docs say: - * - * "Calls to functions whose return value is not affected by changes to - * the observable state of the program and that have no observable - * effects on such state other than to return a value may lend - * themselves to optimizations such as common subexpression elimination. - * Declaring such functions with the const attribute allows GCC to avoid - * emitting some calls in repeated invocations of the function with the - * same argument values." - * - * The word "observable" is important here. With the exception of a - * llvmpipe debug flag behind an environment variable and a few unit tests, - * all of which emulate worse CPUs, this function neither affects nor is - * affected by any "observable" state. It has its own internal state for - * sure, but that state is such that it appears to return exactly the same - * value with the same internal data every time. */ if (unlikely(!p_atomic_read(&_util_cpu_caps_state.detect_done))) call_once(&_util_cpu_caps_state.once_flag, _util_cpu_detect_once); -- GitLab