Recently, GAP headers were rewritten to use static inline functions instead of macros for functionality such as ELM_PLIST() and ADDR_OBJ(). Ward assumes that every function takes care of the appropriate guards itself; because almost all object accesses are now embedded in such static inline functions, no guards are generated at all.
There are two principal options to resolve this issue.
Add guards to static inline functions in header files, too. While this would be comparatively easy (one would just have to add guards to header files and not just .c files), it would leave a lot of optimization potential on the table, as clang/gcc do not know that (for example) guards are loop-invariant code and thus can be moved out of loops. This solution would necessitate teaching C compilers about that aspect of guards, and that may not even be possible. On the other hand, it would allow us to (1) get better performance where Ward misses out on such optimizations and (2) potentially get rid of Ward entirely.
The alternative is to teach Ward about properly processing static inline functions. The basic infrastructure for that is already in place (from earlier versions of Ward, which attempted to do just that for all functions). This infrastructure could be resurrected and applied to Ward, though that would also be a fair amount of work.
Recently, GAP headers were rewritten to use static inline functions instead of macros for functionality such as
ELM_PLIST()andADDR_OBJ(). Ward assumes that every function takes care of the appropriate guards itself; because almost all object accesses are now embedded in such static inline functions, no guards are generated at all.There are two principal options to resolve this issue.
.cfiles), it would leave a lot of optimization potential on the table, as clang/gcc do not know that (for example) guards are loop-invariant code and thus can be moved out of loops. This solution would necessitate teaching C compilers about that aspect of guards, and that may not even be possible. On the other hand, it would allow us to (1) get better performance where Ward misses out on such optimizations and (2) potentially get rid of Ward entirely.