https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285
--- Comment #13 from Antoni <antoyo at gcc dot gnu.org> --- (In reply to David Malcolm from comment #12) > I wonder if we could/should have some kind of builtin that copies uninit > while preserving the "uninitializedness" of it? That example from Godbolt does not use memcpy and I believe we would need a solution for both memcpy and normal integer assignments. In any case, I believe that's the semantics I would want since it would still allow us to see real "use of uninitialized value" that happens afterwards. So, it seems we need to handle 2 cases: * a memcpy that does not warn about uninit, but the results can be uninit (to allow later use to trigger a warning) * a load of an integer (like the godbolt example) that does not warn about uninit, but the result can be uninit as well For the integer case, an idea would be to have sized builtins (load_uninit builtin) like the atomic builtins: __atomic_load_1, __atomic_load_2, __atomic_load_4, __atomic_load_8 and __atomic_load_16. This would be needed for libgccjit which does not have the generic __atomic_load_n builtin. In order to correctly handle the Rust case of MaybeUninit, values produced by that load_uninit builtin would need to behave differently than normal values: when returned or sent as an argument to a function, they should not be considered as a use. I believe it should be reported as a use when sent as an argument to builtins (except a few like memset I believe).
