On Wed, Nov 6, 2024 at 12:43 AM Sam James <s...@gentoo.org> wrote: > > 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
Related https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 . > >
