search for: _memcpy

...PARC. * Neither does Valgrind on Linux. * I've tried increasing the C stack size, assuming R could be running out of stack size. Didn't help. Running R under dbx (without RTC) until the crash shows this: ... About to write t at 1 (l at 1) signal SEGV (no mapping at the fault address) in _memcpy at 0xfe90444b 0xfe90444b: _memcpy+0x006b: movaps 0x00000000(%esi),%xmm0 Current function is H5D_select_mgath 379 HDmemcpy(tgath_buf,buf+off[curr_seq],curr_len); (dbx) where current thread: t at 1 [1] _memcpy(0x0, 0xfdebc707, 0x9f5c4f0), at 0xfe90444b =>[2] H5D_select_mgat...

...guess it is because this memcpy is not coming from the original source, but rather from the initialization code created by clang for the cryptopro_ext local variable. The code that generates that must not honor -fno-builtin. I see this even when I remove -flto (and this gets converted to a call to _memcpy in the final assembly with or without -fno-builtin). I can't do the full LTO link with these options (don't have a windows linker I guess?), and have been unsuccessful in getting the failure with various other options I tried. I wanted to look at the merged LTO code with save-temps. What...

...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 memcpy.c, the lld-link report linking error that it cannot find > the _memcpy symbol as below. In uefi firmware, we have to explicitly > implement these compiler intrinsic functions by ourselves. > > > > > > jshi19 at ub2-uefi-b01:~/llvm/wrongcode/lld-link3$ make > > "/home/jshi19/llvm/llvm-project/releaseinstall/bin/clang" -Oz -flto >...

...`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 memcpy.c, the lld-link report linking error that it cannot find > the _memcpy symbol as below. In uefi firmware, we have to explicitly > implement these compiler intrinsic functions by ourselves. > > > > > > jshi19 at ub2-uefi-b01:~/llvm/wrongcode/lld-link3$ make > > "/home/jshi19/llvm/llvm-project/releaseinstall/bin/clang" -Oz -flto >...

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

.../home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ > CommonProfiling.o:CommonProfiling.c:(.text+0x182): > undefined reference to `_strlen' > /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ > CommonProfiling.o:CommonProfiling.c:(.text+0x19b): > undefined reference to `_memcpy' > /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ > CommonProfiling.o:CommonProfiling.c:(.text+0x1fb): > undefined reference to `_write' > /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ > CommonProfiling.o:CommonProfiling.c:(.text+0x21a): > undefined refe...

...d reference to `_malloc' /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x182): undefined reference to `_strlen' /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x19b): undefined reference to `_memcpy' /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x1fb): undefined reference to `_write' /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x21a): undefined reference to `_write' /home/foad/l...

...reference to `_malloc' /home/ang/build/llvm-coff/runtime/libprofile/Release/ CommonProfiling.o:CommonPro filing.c:(.text+0x182): undefined reference to `_strlen' /home/ang/build/llvm-coff/runtime/libprofile/Release/ CommonProfiling.o:CommonPro filing.c:(.text+0x19b): undefined reference to `_memcpy' /home/ang/build/llvm-coff/runtime/libprofile/Release/ CommonProfiling.o:CommonPro filing.c:(.text+0x1fb): undefined reference to `_write' /home/ang/build/llvm-coff/runtime/libprofile/Release/ CommonProfiling.o:CommonPro filing.c:(.text+0x21a): undefined reference to `_write' /home/ang/...

...jdir-2.6/runtime/libprofile/Release/ >> CommonProfiling.o:CommonProfiling.c:(.text+0x182): >> undefined reference to `_strlen' >> /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ >> CommonProfiling.o:CommonProfiling.c:(.text+0x19b): >> undefined reference to `_memcpy' >> /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ >> CommonProfiling.o:CommonProfiling.c:(.text+0x1fb): >> undefined reference to `_write' >> /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ >> CommonProfiling.o:CommonProfiling.c:(.text+0x21a): &...

..., (%esp) call "_tart.core.Array[tart.core.String]..index.get(int)->tart.core.String" movl %eax, %ebp movl 4(%ebp), %eax movl %eax, 8(%esp) leal 16(%ebp), %eax movl %eax, 4(%esp) movl %esi, (%esp) call _memcpy addl 4(%ebp), %ebx incl %edi cmpl 24(%esp), %edi jne LBB59_5 The issue has to do with the stack variable %index. In the IR code above, %index gets increased by 'length' each time through the loop. %index is also used as an offset to 'dst'...

...profile/Release/ >>> CommonProfiling.o:CommonProfiling.c:(.text+0x182): >>> undefined reference to `_strlen' >>> /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ >>> CommonProfiling.o:CommonProfiling.c:(.text+0x19b): >>> undefined reference to `_memcpy' >>> /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ >>> CommonProfiling.o:CommonProfiling.c:(.text+0x1fb): >>> undefined reference to `_write' >>> /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ >>> CommonProfiling.o:CommonProfilin...

...;>>> CommonProfiling.o:CommonProfiling.c:(.text+0x182): >>>> undefined reference to `_strlen' >>>> /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ >>>> CommonProfiling.o:CommonProfiling.c:(.text+0x19b): >>>> undefined reference to `_memcpy' >>>> /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ >>>> CommonProfiling.o:CommonProfiling.c:(.text+0x1fb): >>>> undefined reference to `_write' >>>> /home/foad/llvm/objdir-2.6/runtime/libprofile/Release/ >>>> CommonProfil...

...thesis/llvm-suite-2.6/llvm-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x182): undefined reference to `_strlen' /cygdrive/c/projects/thesis/llvm-suite-2.6/llvm-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x19b): undefined reference to `_memcpy' /cygdrive/c/projects/thesis/llvm-suite-2.6/llvm-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x1fb): undefined reference to `_write' /cygdrive/c/projects/thesis/llvm-suite-2.6/llvm-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x21a)...

When using the ARM cross compiler we've run into an issue with LTO and optimized libraries. Consider you have an optimized library opt.a, which contains a version of memcpy. Compiling with LTO (something like), clang myTest.c opt.a -flto -o myTest causes myTest.c to get compiled to bitcode. Then the bitcode gets passed to the linker. The linker looks through the bitcode (via

LLVMers, 2.6 pre-release2 is ready to be tested by the community. http://llvm.org/prereleases/2.6/ If you have time, I'd appreciate anyone who can help test the release. To test llvm-gcc: 1) Compile llvm from source and untar the llvm-test in the projects directory (name it llvm-test or test-suite). Choose to use a pre- compiled llvm-gcc or re-compile it yourself. 2) Run make check,