Sam James <s...@gentoo.org> writes: > Alexander Monakov <amona...@ispras.ru> writes: > >> On Fri, 1 Nov 2024, Jan Hubicka wrote: >> >>> > I have a vague memory that one of the tests in SPEC has a loop that >>> > tries to malloc, doubling the size each time, until it fails. Would >>> > the patch change the behavior of such a loop? >>> >>> If the resulting allocation is unused except for NULL check we will make >>> it always "succeed" and thus the loop will likely loop forever. I >>> wonder what this loop computes on systems, like linux, that overcommits >>> memory. >> >> Even with overcommit, malloc is going to return NULL as soon as you pass >> a half or more of the address space as the requested allocation size. >> >> Since the patch eliminates malloc with unknown size, I think this transform >> is incorrect (wasn't correct for the same reason in LLVM either). >> >> I'm pretty sure it's going to break some Glibc tests that verify that >> malloc(SIZE_MAX / 2 + 1) does not succeed. >> >> Please reconsider? Why to we need to match LLVM here? > > Some references to feed discussion which I had in my logs from > discussing it with someone the other week after that interaction we > had with alanc: > * https://github.com/llvm/llvm-project/issues/28790 (not very > insightful, other than to show it has a history of confusing people, but > one might argue that for other (definitely-valid) optimisations) > * https://github.com/llvm/llvm-project/issues/49826 > * https://github.com/llvm/llvm-project/issues/51476
+ https://github.com/llvm/llvm-project/issues/114772
