search for: memcpys

I have found that pid provider can not create memcpy:return probe for 64bit process on snv_110. For example, the pid is 10603, I will have following output for dtrace command: #dtrace -n pid10603:libc.so.1:memcpy:return dtrace: invalid probe specifier pid10603:libc.so.1:memcpy:return: probe description pid10603:libc.so.1:memcpy:return does not match any probes This just

...ource and destination arguments may perfectly alias (otherwise they must not alias at all - memcpy prohibits partial overlap). While the C standard says that memcpy's arguments can't alias at all, perfect aliasing works in practice, and clang currently relies on this behavior: it emits llvm.memcpys for aggregate copies, despite the possibility of self-assignment. Going forward, llvm.memcpy calls emitted for aggregate copies would have mayPerfectlyAlias set to '1'. Other uses of llvm.memcpy (including lowerings from memcpy calls) would have mapPerfectlyAlias set to '0'. This...

Hi, My pass scans call instructions for standard C library calls. For some libc functions, however, LLVM uses intrinsics instead. For example, I see that my memcpy calls are replaced by the llvm.memcpy.* intrinsics. This is not a problem because I can simply look for llvm.memcpy calls when scanning for memcpy calls. The problem arises when LLVM implicitly inserts llvm.memcpy intrinsics into my

I'm trying to understand why using a local memcpy with LTO results in a "multiple definition" error. I have an local (optimized) mempy.c (clearly simplified!): void* memcpy(void* dest, const void* src, unsigned int count) { return 0; } void* __aeabi_memcpy(void *dest, const void *src, unsigned int size) { return memcpy(dest,src,size); } --- I also have a simple

...ource and destination arguments may perfectly alias (otherwise they must not alias at all - memcpy prohibits partial overlap). While the C standard says that memcpy's arguments can't alias at all, perfect aliasing works in practice, and clang currently relies on this behavior: it emits llvm.memcpys for aggregate copies, despite the possibility of self-assignment. >> >> Going forward, llvm.memcpy calls emitted for aggregate copies would have mayPerfectlyAlias set to '1'. Other uses of llvm.memcpy (including lowerings from memcpy calls) would have mapPerfectlyAlias set to ...

On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com>wrote: > > How do I disable that feature? I've tried -fno-builtin and/or >>>>> -ffreestanding >>>>> > with no success. >>>>> clang (as well as gcc) requires that freestanding environment provides >>>>> memcpy, memmove, memset and memcmp.

...must not alias at all - memcpy prohibits >>>> partial overlap). While the C standard says that memcpy's >>>> arguments can't alias at all, perfect aliasing works in practice, >>>> and clang currently relies on this behavior: it emits >>>> llvm.memcpys for aggregate copies, despite the possibility of >>>> self-assignment. >>>> >>>> Going forward, llvm.memcpy calls emitted for aggregate copies >>>> would have mayPerfectlyAlias set to '1'. Other uses of >>>> llvm.memcpy (including...

...> alias (otherwise they must not alias at all - memcpy prohibits > > partial overlap). While the C standard says that memcpy's > > arguments can't alias at all, perfect aliasing works in practice, > > and clang currently relies on this behavior: it emits > > llvm.memcpys for aggregate copies, despite the possibility of > > self-assignment. > > > > Going forward, llvm.memcpy calls emitted for aggregate copies > > would have mayPerfectlyAlias set to '1'. Other uses of > > llvm.memcpy (including lowerings from memcpy calls) would...

On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> > How do I disable that feature? I've tried -fno-builtin and/or >>>>>> -ffreestanding >>>>>> > with no success. >>>>>> clang (as well as gcc)

On Tue, May 29, 2012 at 10:50 AM, Chandler Carruth <chandlerc at google.com> wrote: > On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> wrote: >> >> On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com> >> wrote: >>>>>>> >>>>>>> > How do I disable that feature? I've

+ llvm-dev On 25 Aug 2020, at 13:53, Florian Hahn wrote: > Hi, > > It appears that Clang generates calls to `llvm.memcpy` with > potentially overlapping arguments in some cases. > > For the snippet below > > struct S > { > char s[25]; > }; > > struct S *p; > > void test2() { > ... > foo (&b, 1); > b = a; > b = *p; > ...

...uments may perfectly > alias (otherwise they must not alias at all - memcpy prohibits > partial overlap). While the C standard says that memcpy's > arguments can't alias at all, perfect aliasing works in practice, > and clang currently relies on this behavior: it emits > llvm.memcpys for aggregate copies, despite the possibility of > self-assignment. > > Going forward, llvm.memcpy calls emitted for aggregate copies > would have mayPerfectlyAlias set to '1'. Other uses of > llvm.memcpy (including lowerings from memcpy calls) would have > mapPerfectlyAli...

Usage of the builtin appears independent of LTO, see below. With any of -fno-builtin, -fno-builtin-memcpy, and -ffreestanding, which are all typically used to prevent usage of memcpy calls, we still always get a memcpy builtin in TlsDriverEntryPoint(). I see this even without -flto (e.g. try with just -emit-llvm). I guess it is because this memcpy is not coming from the original source, but

...se they must not alias at all - memcpy prohibits > > > partial overlap). While the C standard says that memcpy's > > > arguments can't alias at all, perfect aliasing works in practice, > > > and clang currently relies on this behavior: it emits > > > llvm.memcpys for aggregate copies, despite the possibility of > > > self-assignment. > > > > > > Going forward, llvm.memcpy calls emitted for aggregate copies > > > would have mayPerfectlyAlias set to '1'. Other uses of > > > llvm.memcpy (including lowerings...

Yeah, it crashes indeed. I can reproduce the problem locally. Let me see what is going on. On Tue, Jul 16, 2019 at 9:00 PM Shi, Steven <steven.shi at intel.com> wrote: > In my previous test case, after add the `-fno-builtin` to clang then > build, the lld-link still has same crash as below: > > > > $ make > >

On Tue, May 29, 2012 at 11:11 AM, Jeffrey Yasskin <jyasskin at googlers.com>wrote: > On Tue, May 29, 2012 at 10:50 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> > wrote: > >> > >> On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com >

Hello, I'm getting the impression that I'm misunderstanding something about intrinsics. I have the following reduced testcase in mind: declare void @llvm.memcpy.i32(i8*, i8*, i32, i32) nounwind define void @foo(i8* %a, i8* %b, i32 %c, i32 %d) { entry: ;call void @llvm.memcpy.i32( i8* %a, i8* %b, i32 %c, i32 %d ) ;call void @llvm.memcpy.i32( i8* %a, i8* %b, i32 0, i32 0 ) ret void

lld should not crash in this case (so that's a bug that needs fixing), but setting it aside, did you try adding `-fno-builtin` to clang so that clang doesn't handle `memcpy` as a built-in function? On Tue, Jul 16, 2019 at 8:46 PM Shi, Steven <steven.shi at intel.com> wrote: > Hi Rui, > > For the test case in my previous email, if I change the `memcpy` to > `foobar` in

On Tue, May 29, 2012 at 9:50 PM, Chandler Carruth <chandlerc at google.com>wrote: > > How do I disable that feature? I've tried -fno-builtin and/or >>>>>>> -ffreestanding >>>>>>> > with no success. >>>>>>> clang (as well as gcc) requires that freestanding environment >>>>>>> provides

Hi Steven, One thing I noticed is that you are defining `memcpy`, which clang has an intrinsic with the same name. Can you try renaming it to a random name, like `foobar`, to see if the problem still exists? On Tue, Jul 16, 2019 at 10:10 AM Shi, Steven <steven.shi at intel.com> wrote: > I’ve submitted a BZ for this issue as below: > > > > Bug 42626 - lld-link crash when