<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 25, 2017 at 6:15 PM, Fabrício Ceolin <span dir="ltr"><<a href="mailto:fabricio.ceolin@miningmath.com" target="_blank">fabricio.ceolin@miningmath.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Thanks. I recompiled everything (on Windows) using this real machine:</div><div><br></div><div>#under msys2</div><div><div>$ cat /proc/cpuinfo</div><span class="gmail-"><div>processor       : 0</div><div>vendor_id       : GenuineIntel</div><div>cpu family      : 6</div></span><div>model           : 23</div><div>model name      : Genuine Intel(R) CPU           U2300  @ 1.20GHz</div><div>stepping        : 10</div><div>cpu MHz         : 1197.000</div><div>cache size      : 1024 KB</div><div>physical id     : 0</div><div>siblings        : 2</div><div>core id         : 0</div><div>cpu cores       : 2</div><div>apicid          : 0</div><div>initial apicid  : 0</div><div>fpu             : yes</div><div>fpu_exception   : yes</div><div>cpuid level     : 13</div><div>wp              : yes</div><div>flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave osxsave lahf_lm dtherm</div><span class="gmail-"><div>clflush size    : 64</div><div>cache_alignment : 64</div></span><div>address sizes   : 36 bits physical, 48 bits virtual</div><div>power management:</div></div><div><br></div><div>but I got the same error:</div><div><br></div><div><div>00007FF85FBF874F 48 83 7A 18 10       cmp         qword ptr [rdx+18h],10h  </div><div>00007FF85FBF8754 48 8B 6A 10          mov         rbp,qword ptr [rdx+10h]  </div><div>00007FF85FBF8758 72 03                jb          std::basic_string<char,std::ch<wbr>ar_traits<char>,std::allocator<wbr><char> >::basic_string<char,std::char<wbr>_traits<char>,std::allocator<<wbr>char> >+2Dh (07FF85FBF875Dh)  </div><div>00007FF85FBF875A 48 8B 32             mov         rsi,qword ptr [rdx]  </div><div>00007FF85FBF875D 48 83 FD 10          cmp         rbp,10h  </div><div>00007FF85FBF8761 73 27                jae         std::basic_string<char,std::c<wbr>har_traits<char>,std::allocato<wbr>r<char> >::basic_string<char,std::char<wbr>_traits<char>,std::allocator<<wbr>char> >+5Ah (07FF85FBF878Ah)  </div><div><b>00007FF85FBF8763 C5 F8 10 06          vmovups     xmm0,xmmword ptr [rsi]  </b></div><div>00007FF85FBF8767 C5 F8 11 01          vmovups     xmmword ptr [rcx],xmm0  </div><div>00007FF85FBF876B 48 89 69 10          mov         qword ptr [rcx+10h],rbp</div></div><div><br></div><div>Are there any parameters that I can use for avoid to use AVX (or better) instructions?</div></div></blockquote><div><br></div><div>LP_NATIVE_VECTOR_WIDTH=128 should force you to a non-avx path. There's also a LP_FORCE_SSE2=1 which will also avoid sse3/4 usage. However all this stuff should be getting detected, so it's odd that it's messing up. Perhaps run with GALLIUM_DUMP_CPU=1 to see what's being detected?<br></div><div><br></div><div>  -ilia</div><div><br></div></div></div></div>