search for: movd

...ing is working fine until samba4 need to update dns when I'm work with more than one DC server. When samba (or bind) need to reload all zones, the module bind9_dlz is shutting down and then all my environment stops and I need to restart the bind to up again. See my log: ... Jan 10 22:32:41 movd-gcp-002 named[9728]: Loading 'lovato.intranet' using driver dlopen Jan 10 22:32:41 movd-gcp-002 named[9728]: samba_dlz: starting configure Jan 10 22:32:41 movd-gcp-002 named[9728]: samba_dlz: Ignoring duplicate zone 'lovato.intranet' from 'DC=@,DC=lovato.intranet,CN=MicrosoftDNS...

.... I saw samba source code and found the destroy dns function in dlz_bind9.c and called by turture blz_bind9.c. When dlz_bind9.c is shutting down, I get this error when I try to update dns. update failed: NOTAUTH Failed nsupdate: 2 update(nsupdate): SRV _ldap._tcp.ForestDnsZones.intranet.dominio movd-gcp-003.intranet.dominio 389 Calling nsupdate for SRV _ldap._tcp.ForestDnsZones.intranet.dominio movd-gcp-003.intranet.dominio 389 (add) Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; UPDATE SECTIO...

...s when I'm work > with more than one DC server. When samba (or bind) need to reload all > zones, the module bind9_dlz is shutting down and then all my environment > stops and I need to restart the bind to up again. > > > See my log: > > > ... > > Jan 10 22:32:41 movd-gcp-002 named[9728]: Loading 'lovato.intranet' using > driver dlopen > Jan 10 22:32:41 movd-gcp-002 named[9728]: samba_dlz: starting configure > Jan 10 22:32:41 movd-gcp-002 named[9728]: samba_dlz: Ignoring duplicate > zone 'lovato.intranet' from 'DC=@,DC=lovato.intr...

...the destroy dns function in dlz_bind9.c and called by turture blz_bind9.c. > > > When dlz_bind9.c is shutting down, I get this error when I try to update > dns. > > > update failed: NOTAUTH Failed nsupdate: 2 update(nsupdate): SRV > _ldap._tcp.ForestDnsZones.intranet.dominio movd-gcp-003.intranet.dominio > 389 Calling nsupdate for SRV _ldap._tcp.ForestDnsZones.intranet.dominio > movd-gcp-003.intranet.dominio 389 (add) Outgoing update query: ;; > ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, > PREREQ: 0, UPDATE: 0, ADDITIONAL...

.... I saw samba source code and found the destroy dns function in dlz_bind9.c and called by turture blz_bind9.c. When dlz_bind9.c is shutting down, I get this error when I try to update dns. update failed: NOTAUTH Failed nsupdate: 2 update(nsupdate): SRV _ldap._tcp.ForestDnsZones.intranet.dominio movd-gcp-003.intranet.dominio 389 Calling nsupdate for SRV _ldap._tcp.ForestDnsZones.intranet.dominio movd-gcp-003.intranet.dominio 389 (add) Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; UPDATE SECTIO...

...bind9.c and called by turture blz_bind9.c. >> >> >> When dlz_bind9.c is shutting down, I get this error when I try to update >> dns. >> >> >> update failed: NOTAUTH Failed nsupdate: 2 update(nsupdate): SRV >> _ldap._tcp.ForestDnsZones.intranet.dominio movd-gcp-003.intranet.dominio >> 389 Calling nsupdate for SRV _ldap._tcp.ForestDnsZones.intranet.dominio >> movd-gcp-003.intranet.dominio 389 (add) Outgoing update query: ;; >> ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, >> PREREQ: 0, UPDAT...

...z_bind9.c. >>> >>> >>> When dlz_bind9.c is shutting down, I get this error when I try to update >>> dns. >>> >>> >>> update failed: NOTAUTH Failed nsupdate: 2 update(nsupdate): SRV >>> _ldap._tcp.ForestDnsZones.intranet.dominio movd-gcp-003.intranet.dominio >>> 389 Calling nsupdate for SRV _ldap._tcp.ForestDnsZones.intranet.dominio >>> movd-gcp-003.intranet.dominio 389 (add) Outgoing update query: ;; >>> ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, >>>...

Hi all, I believe I've found a bug in the encoding of the movd instruction on x64. Here's some IR code to reproduce it: external global i8*, align 1 ; <i8**>:0 [#uses=1] external global i8*, align 16 ; <i8**>:1 [#uses=1] declare void @abort() define internal void @2() { %1 = load i8** @0, align 1 ; <...

On Thu, Jul 9, 2009 at 8:44 AM, Nicolas Capens<nicolas at capens.net> wrote: > I believe I’ve found a bug in the encoding of the movd instruction on x64. > Here’s some IR code to reproduce it: [snip > Note the last movq. What was probably intended to be generated was “movd > ecx, mm0”. LLVM mistakenly sets the ‘wide’ bit of the REX prefix to 1, > turning movd into movq. Also, reg and r/m encoding has been swapped. I h...

...; [esp] = last_error_0 - mov [esp + 4], edx ; [esp + 4] = last_error_1 - mov [esp + 8], esi ; [esp + 8] = last_error_2 - mov [esp + 12], edi ; [esp + 12] = last_error_3 mov ecx, [esp + 40] ; ecx = data_len + test ecx, ecx + jz near .data_len_is_0 + + mov ebx, [esp + 36] ; ebx = data[] + movd mm3, [ebx - 4] ; mm3 = 0:last_error_0 + movd mm2, [ebx - 8] ; mm2 = 0:data[-2] + movd mm1, [ebx - 12] ; mm1 = 0:data[-3] + movd mm0, [ebx - 16] ; mm0 = 0:data[-4] + movq mm5, mm3 ; mm5 = 0:last_error_0 + psubd mm5, mm2 ; mm5 = 0:last_error_1 + punpckldq mm3, mm5 ; mm3 = last_error_1:la...

Hi all, I'm trying to compile asterisk on the mainframe (s390 / s390x) and I am running into issues. I was wondering if somebody could give a hand? I'm thinking that I should be able to do this. I have noticed that Debian even has binary RPM's out for Asterisk now. I'm trying to do this on SuSE SLES8 (with the 2.4 kernel). What I see is, an issue that arch=s390 isn't

...priority for us. I fully understand that having LLVM insert EMMS instructions and trying to prevent it from degrading performance just wasn't worthwhile. Fortunately explicit use of MMX intrinsics is fine for my use. I'm having one remaining issue though; I can't seem to generate the movd instruction(s) (moving 32-bits of data in and out of the lower half of an MMX registers). Take for example the following LLVM IR: define internal void @unpack(i8*, i8*) { %3 = bitcast i8* %1 to i32* %4 = load i32* %3, align 1 %5 = insertelement <2 x i32> undef, i32 %4, i32 0 %6...

...event it from degrading performance just wasn't worthwhile. For what it's worth, LLVM doesn't insert EMMS instructions for you. > Fortunately explicit use of MMX intrinsics is fine for my use. Great! > I'm having one remaining issue though; I can't seem to generate the movd instruction(s) (moving 32-bits of data in and out of the lower half of an MMX registers). Take for example the following LLVM IR: > > define internal void @unpack(i8*, i8*) { > %3 = bitcast i8* %1 to i32* > %4 = load i32* %3, align 1 > %5 = insertelement <2 x i32> undef, i3...

...iately clear. It looks like the successful code is doing an aggregate copy field-by-field while the failing code has lowered this to a memcpy. I would certainly expect the memcpy expansion to be smart enough to avoid using MM registers, though; that's a serious bug if it isn't. movd %xmm0, %rax movd %rax, %mm0 movq2dq %mm0, %xmm1 movq2dq %mm0, %xmm2 punpcklqdq %xmm2, %xmm1 ## xmm1 = xmm1[0],xmm2[0] movq 16(%rsp), %rax movd %rax, %mm0 movq2dq %mm0, %xmm0 punpcklqdq %xmm2, %xmm0 ## xmm0 = xmm0[0],xmm2[0] On Aug 31, 2010, at 11:18 AMPDT, Argyrios Kyrtzidis wrote:...

...tely clear. It looks like the successful code is doing an aggregate copy field-by-field while the failing code has lowered this to a memcpy. I would certainly expect the memcpy expansion to be smart enough to avoid using MM registers, though; that's a serious bug if it isn't. > > movd %xmm0, %rax > movd %rax, %mm0 > movq2dq %mm0, %xmm1 > movq2dq %mm0, %xmm2 > punpcklqdq %xmm2, %xmm1 ## xmm1 = xmm1[0],xmm2[0] > movq 16(%rsp), %rax > movd %rax, %mm0 > movq2dq %mm0, %xmm0 > punpcklqdq %xmm2, %xmm0 ## xmm0 = xmm0[0],xmm2[0] > > > On A...

...cx leaq 8(%rsp), %r8 callq __ZN7WebCore5mouniEPNS_15GraphicsContextEPNS_30GraphicsContextPlatformPrivateERKNS_9FloatRectERNS_10FloatPointES8_ movss 8(%rsp), %xmm0 movss 12(%rsp), %xmm1 subss 20(%rsp), %xmm1 subss 16(%rsp), %xmm0 insertps $16, %xmm1, %xmm0 ## xmm0 = xmm0[0],xmm1[0],xmm0[2,3] movd %xmm0, %rax movd %rax, %mm0 movq2dq %mm0, %xmm1 movq2dq %mm0, %xmm2 punpcklqdq %xmm2, %xmm1 ## xmm1 = xmm1[0],xmm2[0] movq 16(%rsp), %rax movd %rax, %mm0 movq2dq %mm0, %xmm0 punpcklqdq %xmm2, %xmm0 ## xmm0 = xmm0[0],xmm2[0] addq $24, %rsp ret

...254 # 0xfe .byte 255 # 0xff .byte 254 # 0xfe .byte 255 # 0xff .text .globl __unnamed_1 .align 16, 0x90 .type __unnamed_1, at function __unnamed_1: # @2 .Ltmp0: .cfi_startproc # BB#0: movd __unnamed_2+6(%rip), %xmm1 movd __unnamed_2+2(%rip), %xmm0 punpckldq %xmm1, %xmm0 # xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1] movzwl __unnamed_2+8(%rip), %eax movd %eax, %xmm2 movzwl __unnamed_2+4(%rip), %eax movd %eax, %xmm1 punpckldq %xmm2, %xmm1 # xmm1 = xmm1[0],xmm2[0],xmm1[1],xmm2[1]...

...gt; "mov{d|q}\t{$src, $dst|$dst, $src}", > [(store (i64 (vector_extract (v2i64 VR128: > $src), > (iPTR 0))), addr:$dst)]>; > > These say that for an AT&T-style assembler, output movd and for an > Intel > assembler, output movq. Right. > > The problem is that such movs to and from memory must either use movq > or put a rex prefix before the movd. No such rex prefix appears in > these > patterns, meaning the instructions will move 32 bits rather than 6...

...l code is doing an aggregate copy field-by-field while the >> failing code has lowered this to a memcpy. I would certainly >> expect the memcpy expansion to be smart enough to avoid using MM >> registers, though; that's a serious bug if it isn't. >> >> movd %xmm0, %rax >> movd %rax, %mm0 >> movq2dq %mm0, %xmm1 >> movq2dq %mm0, %xmm2 >> punpcklqdq %xmm2, %xmm1 ## xmm1 = xmm1[0],xmm2[0] >> movq 16(%rsp), %rax >> movd %rax, %mm0 >> movq2dq %mm0, %xmm0 >> punpcklqdq %xmm2, %xmm0 ## xmm0 = xmm0[...

...ns i64mem:$dst, VR128: $src), "mov{d|q}\t{$src, $dst|$dst, $src}", [(store (i64 (vector_extract (v2i64 VR128:$src), (iPTR 0))), addr:$dst)]>; These say that for an AT&T-style assembler, output movd and for an Intel assembler, output movq. The problem is that such movs to and from memory must either use movq or put a rex prefix before the movd. No such rex prefix appears in these patterns, meaning the instructions will move 32 bits rather than 64 bits. Bad things happen. A little sleuthin...