https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Patrick J. LoPresti from comment #29)
> (In reply to Jakub Jelinek from comment #27)
> >
> > No, that is not a reasonable fix, because it severely pessimizes common code
> > for a theoretical only problem.
>
> The very existence of (and interest in) this bug report means it is
> obviously not "a theoretical only problem".
>
> And of course Rich Felker is correct that the cost of the obvious fix is
> trivial and not remotely "severe".
But I didn't see a patch proposed to address this issue, which means it
doesn't seem to be trivial.
> But the bottom line is that GCC is emitting library calls that invoke
> undefined behavior. At a minimum, GCC should document this non-standard
> requirement on its runtime environment. Has anyone bothered to do that? Why
> not?
I think it's written down somewhere but I can't quickly find it (I also
wonder where exactly the best place to document would be - it's related
to porting GCC to a new target architecture I guess, not so much user-facing).
OTOH I see
@cindex @code{cpymem@var{m}} instruction pattern
@item @samp{cpymem@var{m}}
...
The @code{cpymem@var{m}} patterns need not give special consideration
to the possibility that the source and destination strings might
overlap. These patterns are used to do inline expansion of
@code{__builtin_memcpy}.
which is possibly the closest piece we have and which fails to mention
exact overlap. I'll propose an adjustment to this.
