Make sure the GCC backend does not assume "pointer lifetime end zap" rules

C has some very peculiar UB. For instance, when an allocation gets freed, then all pointers to that allocation become indeterminate values. This is sometimes called "pointer lifetime end zap". This means the following code has UB in C:

int *x = malloc(100);
free(x);
// Looking at x again is UB!
if ((uintptr_t)x == 1024) { printf("Hello!\n"); }

Obviously, the equivalent code in Rust is well-defined. Therefore, it would be good to make sure that whatever parts of GCC the backend is using are aware that Rust does not have pointer-lifetime-end-zap. I am somewhat concerned that GCC is modeled closely after C semantics and hence implicitly applies rules like that -- but I don't know how one would even begin to figure this out. Is there something like a LangRef for the GCC IR(s)?

Start by investigating the GCC backend and the libgccjit/GCC IR semantics relevant to pointer values after allocation lifetime ends. Determine whether Rust code generation relies on C-style pointer-lifetime-end behavior, then validate that the backend preserves Rust's defined behavior; the issue provides no specific file or test to run.