search for: 170h

...o a case, where x86 fails to run correctly. Checking into the emitted code, it seems that the local memory anchored at ebp has conflict with stack memory anchored at esp prepared for function calls. For example, let us say: foo() { ... call bar(); } There is some local data for foo() at ebp-170h. while preparing the call to bar, some data is written to esp+17h. The problem is that esp+17h and ebp-170h point to the same address, and therefore the data is corrupted. Has anyone seen this problem before? and is there any fix or work around for that? Thanks! -Peng -------------- next pa...

...,xmmword ptr ds:[2B0020h] 002B07AD movaps xmm4,xmmword ptr [esp+190h] 002B07B5 mulpd xmm4,xmm1 002B07B9 mulpd xmm4,xmm4 002B07BD movaps xmm5,xmmword ptr [esp+180h] 002B07C5 mulpd xmm5,xmm1 002B07C9 mulpd xmm5,xmm5 002B07CD movaps xmmword ptr [esp+170h],xmm0 002B07D5 mulpd xmm0,xmm1 002B07D9 mulpd xmm0,xmm0 002B07DD addpd xmm4,xmm5 002B07E1 addpd xmm4,xmm0 002B07E5 movapd xmm0,xmmword ptr ds:[2B0030h] 002B07ED movaps xmm1,xmm0 002B07F0 subpd xmm1,xmm4 002B07F4 movapd xmm4,xmmword ptr ds...

Hmm, I'm not able to get those .ll files to compile if I disable SSE and I end up with SSE instructions(including sqrtpd) if I don't disable it. On Thu, Jul 18, 2013 at 10:53 PM, Peter Newman <peter at uformia.com> wrote: > Is there something specifically required to enable SSE? If it's not > detected as available (based from the target triple?) then I don't think