similar to: [LLVMdev] Fix crash in llvm_gcda_emit_arcs()

Hi Nick, Thanks for looking over my patch. I'd be happy to add the compare against cur_buffer_size. I'll try to write up such a change today and then send a new patch to the list. Joseph Kain On Thu, Sep 5, 2013 at 1:37 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Bill, could you take a look at this? I don't have a checkout of > compiler-rt that builds. > >

Bill, could you take a look at this? I don't have a checkout of compiler-rt that builds. It seems obviously-correct to me, but I wish it did a compare against cur_buffer_size to make sure it's in range. Nick Joseph Kain wrote: > Hi, > > I've been seeing a crash in llvm_gcda_emit_arcs() on x86_64. The crash > occurs executing a movdqa instruction with an unaligned src

Hi Nick and Bill, Attached is a new version of the patch that checks against cur_buffer_size. This works with the cases I've been using but again I haven't run the official tests on this change. Thanks, Joseph Kain On Thu, Sep 5, 2013 at 9:46 AM, Joseph Kain <joekain at gmail.com> wrote: > Hi Nick, > > Thanks for looking over my patch. I'd be happy to add the

Hi, I am trying to test my project and get the code coverage with a version of clang compiler that was built from the latest llvm/clang codebase. It worked for a while. But today, after I updated my local checkout, and re-build llvm, clang and compiler-rt, when I test my project again, I got the errors with undefined reference to 'llvm_gcda_start_file', 'llvm_gcda_emit_arcs',

Thanks for your reply. May I know which is the recommended library that should be linked against? I am currently linking libprofile_rt.a. And I have noticed the differences that, if we do `nm libprofile_rt.a | grep llvm` with my old copy of the llvm/clang installation, I can see 00000000000005e0 T _llvm_gcda_emit_arcs 0000000000000b48 S _llvm_gcda_emit_arcs.eh 0000000000000430 T

Qun Fa wrote: > Hi, > I am trying to test my project and get the code coverage with a version > of clang compiler that was built from the latest llvm/clang codebase. > > It worked for a while. But today, after I updated my local checkout, and > re-build llvm, clang and compiler-rt, when I test my project again, I > got the errors with undefined reference to

On Fri, Mar 15, 2013 at 1:36 AM, Qun Fa <testforqunfa at gmail.com> wrote: > Hi All, > > I think Nick's suggestion is correct, my code was linked against > libprofile_rt.a, which had gcda profiling code before, but was removed > https://github.com/llvm-mirror/llvm/commit/218042a02305a3cc38d968a97ff9ecf4b4abe6ff > > So, I couldn't find the correct symbols from

Hi All, I think Nick's suggestion is correct, my code was linked against libprofile_rt.a, which had gcda profiling code before, but was removed https://github.com/llvm-mirror/llvm/commit/218042a02305a3cc38d968a97ff9ecf4b4abe6ff So, I couldn't find the correct symbols from libprofile_rt.a any more. Now my assumption is I need to use the correct library that is provided by compiler-rt.

Hi! On Fri, Mar 15, 2013 at 10:51 PM, Qun Fa <testforqunfa at gmail.com> wrote: > Thank you Alexey. > > I have tried to use Makefile. This will generate the correct symbols that > I need. > > Any idea on the schedule of adding CMake support to compiler-rt? > Starting from r177382 CMake on Linux should build the same profile compiler-rt library as Makefiles. >

Thank you Alexey. I have tried to use Makefile. This will generate the correct symbols that I need. Any idea on the schedule of adding CMake support to compiler-rt? Sincerely, Qun On Fri, Mar 15, 2013 at 1:51 AM, Alexey Samsonov <samsonov at google.com>wrote: > > On Fri, Mar 15, 2013 at 1:36 AM, Qun Fa <testforqunfa at gmail.com> wrote: > >> Hi All, >>

Thank you Alexey. I will try this out this week. Any idea on supporting this for Mac? My raw idea is to add this to compiler-rt/lib/profile/CMakeLists.txt if(APPLE) foreach(arch ${PROFILE_SUPPORTED_ARCH}) add_compiler_rt_static_runtime(clang_rt.profile-${arch} ${arch} SOURCES ${PROFILE_SOURCES} CFLAGS --sysroot=${COMPILER_RT_DARWIN_SDK_SYSROOT}) endforeach() endif() Do you

On Mon, Mar 25, 2013 at 5:04 PM, Qun Fa <testforqunfa at gmail.com> wrote: > Thank you Alexey. I will try this out this week. Any idea on supporting > this for Mac? > > My raw idea is to add this to compiler-rt/lib/profile/CMakeLists.txt > > if(APPLE) > foreach(arch ${PROFILE_SUPPORTED_ARCH}) > add_compiler_rt_static_runtime(clang_rt.profile-${arch} ${arch}

Hi Everyone, I have uploaded a patch that allows one to successfully gather gcov/gcda coverage information on programs which unload shared libraries. It¹s a simple fix, just adding a few COMPILER_RT_VISIBILITY (i.e. __attribute__((visibility("hidden")))) in GCDAProfiling.c. Now, I¹d like to include a test program to demonstrate the fix. AFAICT, there seems to be a single test for

I'm migrating from a (set of) NT domain, say SANVITO, to an AD domain, say LNFFVG. Both domain live in the same network, so there's no firewall/routing/... in the middle. In SANVITO domain, there's a share (say \\MEDIA\Software) with public access enabled. In SANVITO domain, public access works as expected. The same share are accessible with login (and password; so, non

Mandi! Rowland Penny via samba In chel di` si favelave... > I am not disputing what you say, I am just asking for concrete proof > that a computer account MUST have a uidNumber account. Rowland, it is not (only) a matter of authentication, it is a matter of 'act' with machine account. I've digged a bit but found nothing than (i use WPKG as deployment system, it is only an

We see the MOVQ instruction but this patch deliberately uses it rather than MOVQDA (load 128-bits aligned). We were seeing that with the trace below, the final invocation is not 128-bit aligned but MOVQDA insists on it (the calling function was pitch_sse4_1.c:90, in the 4-way N - i >= 4 loop). 07-31 11:00:13.469 210 2540 <(469)%20210-2540> D opus_sse1: RBE celt_inner_prod_sse4_1: x

Jonathan, Here's the code difference we see with the recent change -- what amounts to reverting your change from a couple years back. It doesn't look like we're getting superfluous instructions from clang now. the bad behavior for us was the alignment exception on the movdqa instructions when the input data wasn't 128-bit aligned. We had to change something because the code as-is

Hello. This is my 1st post. I have tried SSE execution domain fixup pass. But I am not able to see any improvements. I expect for the example below to use MOVDQA, PAND &c. (On nehalem, ANDPS is extremely slower than PAND) Please tell me if something would be wrong for me. Thank you. Takumi Host: i386-mingw32 Build: trunk at 103373 foo.ll: define <4 x i32> @foo(<4 x i32> %x,

On Thu, Aug 3, 2017 at 6:19 PM, Tim Northover <t.p.northover at gmail.com> wrote: > 2017-08-03 8:58 GMT-07:00 Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org>: > > The error is gone after removing (or reducing) the alignment of `%a`. > This > > makes me believe that our inline asm syntax is correct to add an offset > to a > > pointer: "

> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Marco Gaiarin via samba > Verzonden: maandag 15 januari 2018 13:03 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] Avoiding uid conflicts between rfc2307 > user/groups and computers > > Mandi! Rowland Penny via samba > In chel di` si favelave... > >