https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #69 from post+gcc at ralfj dot de --- Ah, I guess that would be https://gcc.gnu.org/onlinedocs/gcc/Standards.html, thanks. So that puts the ball in gblic's court, which is tracked at https://sourceware.org/bugzilla/show_bug.cgi?id=31055. Until that is resolved, technically using GCC and GNU libc together is unsupported since GCC makes assumptions that glibc does not guarantee. And worse, glibc uses "restrict" in its "memcpy", which according to GCC's semantics means glibc *cannot* make such a guarantee without removing "restrict". Arguably there is still a bug in GCC here: the assumption GCC makes about memcpy is in contradiction with GCC's own specification (as inherited from the C standard) for what the standard signature of memcpy means when compiled with GCC.
