Sony PS5's clang `-fmerge-all-constants` causes crash during initialization

[f32y]

Hi,
I observed wierd crashes after upgrading mimalloc from v3.0 to v3.4.3. Crash stack looks like this:

libc.prx!abort + 16 bytes	Unknown	Symbols loaded.
PS5Player_IL2CPP_d.self!mi_error_default(int err) Line 592 + 5 bytes	C	Symbols loaded.
PS5Player_IL2CPP_d.self!_mi_error_message(int err, const char* fmt, ...) Line 625	C	Symbols loaded.
PS5Player_IL2CPP_d.self!mi_heap_init_theap(const mi_heap_t* const_heap) Line 63	C	Symbols loaded.
PS5Player_IL2CPP_d.self!_mi_heap_theap_get_or_init(const mi_heap_t* heap) Line 92 + 9 bytes	C	Symbols loaded.
PS5Player_IL2CPP_d.self!_mi_heap_theap(const mi_heap_t* heap) Line 533 + 9 bytes	C	Symbols loaded.
PS5Player_IL2CPP_d.self!mi_heap_malloc_aligned(mi_heap_t* heap, size_t size, size_t alignment) Line 308 + 9 bytes	C	Symbols loaded.
<...>
<thread entry>

After some debugging I found that this is caused by clang's -fmerge-all-constants optimization. Sony PS5 uses a customized clang (clang version 21.1.7) and it merges _mi_theap_empty and _mi_theap_empty_wrong into one address, and bad things happen. This can be confirmed in Visual Studio's watch window:

(void*)&_mi_theap_empty 0x000000007073ef40 {_mi_theap_empty_wrong}
(void*)&_mi_theap_empty_wrong 0x000000007073ef40 {_mi_theap_empty_wrong}

Changing one ctor to be different from another one can fix this problem:

mi_decl_cache_align const mi_theap_t _mi_theap_empty_wrong = {
  &tld_empty,             // tld
  MI_ATOMIC_VAR_INIT(NULL), // heap
  MI_ATOMIC_VAR_INIT(1),  // refcount
  MI_ATOMIC_VAR_INIT(0),  // freed
  0,                      // heartbeat
  1,                      // cookie       // <--------- change from 0 to 1
// ...
};

Now _mi_theap_empty and _mi_theap_empty_wrong will not be merged:

(void*)&_mi_theap_empty 0x000000002d4baf40 {_mi_theap_empty}
(void*)&_mi_theap_empty_wrong 0x000000002d4bcf40 {_mi_theap_empty_wrong}

[Zoxc]

Opus spotted a write to _mi_theap_empty (bug 6 in the list I sent to @daanx). That may be related.

[daanx]

Thank you @f32y -- that is a vicious bug :-) I pushed your cookie fix.
@Zoxc: this was unrelated, but bug 6 was indeed the case for zero sized objects (fixed as well now).