https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99860
--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> --- Quoting Paul Eggert here: https://lists.gnu.org/archive/html/bug-gnulib/2022-07/msg00066.html > I looked into this a bit more, and it turns out that GCC was wrong > about > what happens when some parameters have 'restrict' and others do not, > and > this was partly because the C Standard itself is so opaque. (The GCC > bug > has been fixed.) > > In 2018 Troy Johnson and Bill Homer of Cray proposed[1] adding > examples > to the C standard to try to make it clearer what happens when some > function parameters are 'restrict' and others are not. These examples > have been added (with some changes) to section 6.7.3.1 of the current > (June 2022) draft of the next C standard.[2] Perhaps they will help > explain things better. > > The confusion in this obscure area for so many years suggests that > Gnulib would be better off following the lead of POSIX and the C > standard, by using 'restrict' on all relevant parameters rather than > trying to be clever and use 'restrict' with only some parameters. > Although omitting some 'restrict's shortens the code, it complicates > analysis (for both humans and compilers) so much that it's more > trouble > than its worth. > > [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2260.pdf > [2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf >
