You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although the RMM code tries to avoid this, developers are not infallible and may write code with undefined behavior. Enabling this warning option for the compiler is desirable to flag such code. Whether the option is set to 2 or 1 depends on how many false positives are flagged by the option.
GCC (and presumably Clang) does provide an escape hatch for the situations where it's really necessary to create an aliasing pointer of a different type: https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-may_005falias-type-attribute. Hopefully RMM doesn't have such cases but if it does, we should be able to reason about this and be convinced that the aliasing is indeed safe and intentional.
The text was updated successfully, but these errors were encountered:
The compiler may choose to optimize code based on strict aliasing assumptions as documented here : https://en.cppreference.com/w/c/language/object#Strict_aliasing
Although the RMM code tries to avoid this, developers are not infallible and may write code with undefined behavior. Enabling this warning option for the compiler is desirable to flag such code. Whether the option is set to 2 or 1 depends on how many false positives are flagged by the option.
GCC (and presumably Clang) does provide an escape hatch for the situations where it's really necessary to create an aliasing pointer of a different type: https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-may_005falias-type-attribute. Hopefully RMM doesn't have such cases but if it does, we should be able to reason about this and be convinced that the aliasing is indeed safe and intentional.
The text was updated successfully, but these errors were encountered: