Recent searches
Search options
So much fun when clang optimizes out your autoconf checks:
https://gitlab.freedesktop.org/xorg/util/macros/-/issues/4
@alanc You could also maybe fix it by moving those variables out of the function, like this: https://godbolt.org/z/sxG6eaWMx
edit: ...the idea being that gcc optimized them out because it noticed they weren't being used. By assigning the values to globals it can't reason about how they might be used by other compilation units
@thesamesam @alanc Maybe just pass it to an inline asm, then? https://godbolt.org/z/evjvoYP1K
@vegard @thesamesam @alanc this demonstrates a strange optimization weakness in LLVM, because the asm does not modify its input
asms would need to be asm("" : "+r"(arg)) and you'd need to pass an lvalue to them
but wrapping the output of malloc in an asm does not solve the initial problem fully: if the compiler assumes that malloc(0) returns 0, it will make that substitution, and no amount of wrapping the 0 in asm will make the test invoke malloc
@amonakov @vegard @alanc Right: https://github.com/llvm/llvm-project/issues/51476. But as came up before, interposition makes the check unsound anyway too.
@thesamesam @amonakov @vegard unfortunately, while testing a patch to assume malloc(0) can return NULL in any case, I've hit errors from gcc 14 seemingly thinking our malloc macros limit the array bounds to be either 0 or 1:
@thesamesam @amonakov @vegard https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/267 hacks around those - they seem like bugs in gcc's -Warray-bounds but since 14.2 is already shipping, we need to be able to work with it.
@alanc @thesamesam @amonakov @vegard My guess: The size computation can wrap around and it that case there could be an oob access.
@alanc @thesamesam @vegard such warnings are often confusing, but if it helps, I can suggest that you treat those as if the compiler was telling you: when the computation in a 32-bit int feeding the size argument of malloc overflows, you're gonna have a bad time
(not that you wouldn't have a bad time before the patch, but now there's an explicit check for (potentially overflowed) size being 0, so the compiler — probably as a result of CFG path specialization — considers that possibility)
@amonakov @alanc @thesamesam @vegard An "int" overflowing leads to a very large input to malloc which yields a different warning. Here it lookg more like the unsigned computation in size_t.
https://godbolt.org/z/dvaE8vE76
@thesamesam @amonakov @vegard so now that those are fixed, I've proposed gutting the test anyway, to make it safer to interpose different malloc implementations:
https://gitlab.freedesktop.org/xorg/util/macros/-/merge_requests/9
(Though as shown there, builders already can force that via the --enable-malloc0returnsnull configure flag.)