https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #62 from Rich Felker ---
The process described there would have to end at least N bits before the end of
the destination buffer. The point was that it would destroy information
internal to the buffer at each step along the way,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #61 from Richard Earnshaw ---
Then I don't understand what you're trying to say in c57.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #60 from Rich Felker ---
Nobody said anything about writing past end of buffer. Obviously you can't do
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #59 from Richard Earnshaw ---
Memcpy must never write beyond the end of the specified buffer, even if reading
it is safe. That wouldn't be thread safe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #58 from Jakub Jelinek ---
(In reply to Rich Felker from comment #57)
> and more concerned about the consequences of LTO/whole-program-analysis where
> something in the translation process can see the violated restrict
> qualifier,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #57 from Rich Felker ---
I think one could reasonably envision an implementation that does some sort of
vector loads/stores where, due to some performance constraint or avoiding
special casing for possible page boundary past the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #56 from Richard Earnshaw ---
I've never heard of a memcpy implementation that corrupts data if called with
memcpy (p, p, n). (The problems come from partial overlaps where the direction
of the copy may matter).
Has anybody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #55 from Florian Weimer ---
(In reply to post+gcc from comment #52)
> For the point discussed earlier with the `restrict` in the musl memcpy, I
> had another look at the definition of `restrict` and it's not entirely clear
> to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #54 from Richard Biener ---
(In reply to post+gcc from comment #52)
> For the point discussed earlier with the `restrict` in the musl memcpy, I
> had another look at the definition of `restrict` and it's not entirely clear
> to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #53 from rguenther at suse dot de ---
On Tue, 28 Nov 2023, post+gcc at ralfj dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
>
> --- Comment #51 from post+gcc at ralfj dot de ---
> Oh great, I love it when one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #52 from post+gcc at ralfj dot de ---
For the point discussed earlier with the `restrict` in the musl memcpy, I had
another look at the definition of `restrict` and it's not entirely clear to me
any more that there is UB here. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #51 from post+gcc at ralfj dot de ---
Oh great, I love it when one part of the C standard just adds exceptions to
statements made elsewhere. It's almost as if the authors want this to be as
hard to understand as possible...
That then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #50 from joseph at codesourcery dot com ---
Qualifiers on function parameter types do not affect type compatibility or
composite type (see 6.7.6.3#14). I think they're only actually of
significance in the definition; in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #49 from post+gcc at ralfj dot de ---
Even glibc itself seems to use `restrict`:
https://codebrowser.dev/glibc/glibc/string/string.h.html#43
So the compiler building glibc might inadvertently rely on the memory written
through dst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #48 from post+gcc at ralfj dot de ---
> Note, clang makes the same assumption apparently (while MSVC emits rep movs
> inline and ICC either that, or calls _intel_fast_memcpy).
MSVC does the same thing as clang and GCC, if godbolt is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #47 from Jakub Jelinek ---
(In reply to Richard Biener from comment #46)
> So yes, the most clean solution would be to have __forgiving_memcpy
> possibly also allowing NULL pointers when n == 0 besides allowing
> the exact overlap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #46 from Richard Biener ---
I'll note that restrict on the parameters can help optimizing the copying loop
because you can then unroll and hoist loads before stores. I'll also note that
almost all (important) targets implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #45 from Tim Ruffing ---
Ha, I didn't want to move to discussion about restrict, but as a final remark:
The formal semantics of restrict are not easy to parse and understand (see
https://www.iso-9899.info/n3047.html#6.7.3.1 ). But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #44 from Rich Felker ---
My naive expectation is that "if ((uintptr_t)src == 0x400400)" is and should be
UB, but I may be misremembering the details of the formalism by which the spec
for restrict is implemented.
If so, that's kinda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #43 from post+gcc at ralfj dot de ---
That is not my reading of the standard, but absent a proper (formal,
mathematical) spec I guess it is hard to tell.
With your reading, "if ((uintptr_t)src == 0x400400)" is UB, since changing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #42 from Rich Felker ---
> I'm not saying that such an implementation will be a good idea, but just a
> remark: You could, in fact, keep restrict for the arguments in this case,
> because the object pointed to by src and dest is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #41 from post+gcc at ralfj dot de ---
> This entitles a compiler to emit asm equivalent to if (src==dest) system("rm
> -rf /") if it likes.
No it does not. restrict causes UB if the two pointers are used to access the
same memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #40 from Sam James ---
https://git.musl-libc.org/cgit/musl/tree/src/string/memcpy.c#n5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #39 from Tim Ruffing ---
(In reply to Rich Felker from comment #36)
> Our memcpy is not written in asm but in C, and it has the restrict qualifier
> on src and dest.
For my curiosity, can you point me to this implementation? I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #38 from Tim Ruffing ---
(In reply to Rich Felker from comment #36)
> If you're happy with a branch, you could probably take restrict off the
> arguments and do something like:
>
> if (src==dest) return;
> const char *restrict src2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #37 from Rich Felker ---
Also: has anyone even looked at what happens if a C memcpy with proper use of
restrict gets LTO-inlined into a caller with GCC-generated memcpy calll where
src==dest? That sounds like a case likely to blow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #36 from Rich Felker ---
> the assembly generated by the current implementations already supports that
> case.
Our memcpy is not written in asm but in C, and it has the restrict qualifier on
src and dest. This entitles a compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #35 from Jakub Jelinek ---
Note, clang makes the same assumption apparently (while MSVC emits rep movs
inline and
ICC either that, or calls _intel_fast_memcpy). As I mentioned earlier, if
glibc and other libraries provide an alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #34 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:7758cb4b53e8a33642709402ce582f769eb9fd18
commit r14-5772-g7758cb4b53e8a33642709402ce582f769eb9fd18
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #33 from rguenther at suse dot de ---
On Thu, 23 Nov 2023, fw at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
>
> --- Comment #32 from Florian Weimer ---
> There's this in standards.texi:
>
> Most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #32 from Florian Weimer ---
There's this in standards.texi:
Most of the compiler support routines used by GCC are present in
@file{libgcc}, but there are a few exceptions. GCC requires the
freestanding environment provide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #31 from Richard Biener ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #30 from post+gcc at ralfj dot de ---
There have been several assertions above that a certain way to solve this
either has no performance cost at all or severe performance cost. That sounds
like we are missing data -- ideally, someone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #29 from Patrick J. LoPresti ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #28 from Rich Felker ---
> No, that is not a reasonable fix, because it severely pessimizes common code
> for a theoretical only problem.
Far less than a call to memmove (which necessarily has something comparable to
that and other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #27 from Jakub Jelinek ---
(In reply to Rich Felker from comment #26)
> > The only reasonable fix on the compiler side is to never emit memcpy but
> > always use memmove.
>
> No, it can literally just emit (equivalent at whatever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #26 from Rich Felker ---
> The only reasonable fix on the compiler side is to never emit memcpy but
> always use memmove.
No, it can literally just emit (equivalent at whatever intermediate form of):
cmp src,dst
je 1f
call memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #25 from rguenther at suse dot de ---
On Tue, 21 Nov 2023, bugdal at aerifal dot cx wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
>
> Rich Felker changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
post+gcc at ralfj dot de changed:
What|Removed |Added
CC||post+gcc at ralfj dot de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #22 from Patrick J. LoPresti ---
I disagree that bug 108296 is a duplicate. That bug requires code that, at
least arguably, invokes undefined behavior. See e.g.
https://stackoverflow.com/q/7292862/ and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #21 from Nadav Har'El ---
This old problem has become a real problem in gcc 12 with a real effect on
incorrect code generation, where code that copies an object was incorrectly
"optimized" to use __builtin_memcpy() instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Andrew Pinski changed:
What|Removed |Added
CC||nyh at math dot technion.ac.il
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #19 from rguenther at suse dot de ---
On Wed, 9 Jun 2021, public at timruffing dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
>
> Tim Ruffing changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Tim Ruffing changed:
What|Removed |Added
CC||public at timruffing dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #17 from Alexander Cherepanov ---
On 2016-04-25 17:34, joseph at codesourcery dot com wrote:
> Or it could simply document an additional requirement on the C library
> used with GCC (that the case of exact overlap works), just as it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #16 from Patrick J. LoPresti ---
Well, Valgrind itself is another real-world example. Tools like Valgrind cannot
distinguish invalid memcpy() calls by the programmer from invalid memcpy()
calls emitted by GCC.
You can, of course,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #15 from joseph at codesourcery dot com ---
On Sun, 24 Apr 2016, lopresti at gmail dot com wrote:
> That said, this is clearly a real bug in GCC. memcpy has a well-defined
> interface; GCC emits calls violating that interface;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #14 from Patrick J. LoPresti ---
D Hugh Redelmeier in comment 12 is mistaken... memcpy is a reserved identifier
(see e.g. http://stackoverflow.com/a/23841970), so the user cannot legally
redefine it.
That said, this is clearly a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
D. Hugh Redelmeier changed:
What|Removed |Added
CC||hugh at mimosa dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
One way to fix this is to emit the memcpy as
if (p != q)
memcpy (p, q, ...);
but of course that comes at a cost in code-size and runtime for no obvious good
reason (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC||msebor at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Summary|builtin operator= generates |block copy
55 matches
Mail list logo
