https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21111
--- Comment #11 from Alexander Monakov <amonakov at gcc dot gnu.org> --- (In reply to Richard Biener from comment #10) > Hmm, I don't remember whether uninit reads invoke undefined behavior, esp. > result in a trap representation, but the original testcase doesn't seem to > read uninitialized things. Neither the original nor the updated testcase invoke UB, but to answer the question, C11 says uninit reads invoke UB if the object could have been declared with the 'register' keyword, otherwise it results in an indeterminate value (which can be a trap representation if its type allows that). > For it I suspect that store_bitfield is at fault given it will read possibly > uninitialized values for the RMW cycle it performs. I think store_bit_field is fine. I'd say the problem is that "birth" of an object does not result in any tidying/preparing for the underlying storage on RTL. But (except for specific case of probing the stack for large objects) other targets don't need any such tidying afaik (except for a related SIMT issue on NVPTX). > So one of the questions is whether we have to / want to preserve any NaT > in non-speculated code which means simply clearing NaT everywhere in a > mdreorg-like pass? Given the above, I suspect it cannot be fully solved with a late RTL pass: one hardreg may be reused for two different objects, and an attempted speculation on the first object may leave the NaT bit set for the second object.
