https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96987
--- Comment #6 from Iain Buclaw <ibuclaw at gdcproject dot org> --- (In reply to Martin Sebor from comment #5) > A void pointer is usually cast to one to a complete type that's then used to > access the object (e.g., bsearch). But not every instance of every warning > should be expected to indicate a bug. Most only suggest that there might be > one. The documented purpose of GCC warnings is to "report constructions > that are not inherently erroneous but that are risky or suggest there may > have been an error." This rare use is one such case. It was considered > when the warning was designed and deemed an acceptable trade-off. (The > attribute was added to help accommodate it.) > > If adding support for attribute access to the D front end isn't feasible to > mark up the function and avoid the warning that way, I would suggest > removing the const qualifier from the pointer (following the practice of the > C++ standard garbage collector APIs) or providing an non-const overload. > Alternatively, writing into a byte of the allocated memory will prevent the > warning as well. Changing the API is not really an option as that sits in upstream. Thinking more about it. Though it isn't immediately intuitive, one implication of the warning could be that the GC may run a mark/sweep between the time GC.addRange is called and the allocated data being initialized, thus leading to the possibility of false pointers being seen during the scan. So I'll relax my stance on this, however was certainly thrown off by the way the warning presented itself as shown in pr96989.
