<div dir="ltr"><div><div><div>I think as you alluded to, movaps xmm, m128 requires m128 to be 16 byte aligned to load 4 single precision fp into xmm.<br></div>Glibc had a bug open for not supporting variable alignment on malloc/new as standard mandates it, but they decided not to fix according to this bug <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795</a><br></div>The issue is 'resolved wontfix' but I'm not exactly sure what they decided to do -- it seems they tried to put in workaround in gcc as glibc won't budge. If workaround is in gcc, clang for sure would also need that.<br><br></div>-Kevin<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 2, 2017 at 6:44 PM, Craig Topper via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Does the crash happen if you compile with -fnew-alignment=8? That's supposed to change what clang assumes the alignment of memory allocated with new will be.</div><div class="gmail_extra"><br clear="all"><div><div class="m_-1376098337422870178gmail_signature" data-smartmail="gmail_signature">~Craig</div></div>
<br><div class="gmail_quote"><div><div class="h5">On Mon, Oct 2, 2017 at 3:11 PM, Riyaz Puthiyapurayil via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div link="#0563C1" vlink="#954F72" lang="EN-US">
<div class="m_-1376098337422870178m_-4238045200672268176WordSection1">
<p class="MsoNormal">I have some programs crashing when I upgraded from clang 3.9.1 to clang 4.0.1.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Debugging this I found the reason for the crash. This is happening in the following assembly fragment for a piece of code allocating a class object (size: 24 bytes) using operator new and then initializing it:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-family:Consolas"> 0x00002aaaafc145f3 <+35>: callq 0x2aaaafdf5f90 <operator new(unsigned long)><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas"> 0x00002aaaafc145f8 <+40>: mov %rax,%r13<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas"> 0x00002aaaafc145fb <+43>: xorps %xmm0,%xmm0<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">=> 0x00002aaaafc145fe <+46>:
<span style="color:red">movaps %xmm0,0x0(%r13)</span><u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The value in %r13 (from the return value of operator new) is not appropriately aligned causing the crash. The memory allocation is done by a custom memory allocator that is returning 8-byte aligned blocks. The memory allocator has not changed
between the two versions of the program (the one using clang 3.9.1 versus the one using clang 4.0.1). The version of libstdc++ is also the same. The command line options to clang are unchanged (-msse2 is specified in both cases). But I found that clang 3.9.1
is not generating SSE instructions but clang 4.0.1 is generating them in the above case.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The fix in our code is to make an API call to configure the custom allocator to always return appropriately aligned memory. But I would like to know if there is a known change in LLVM or clang to assume that malloc will return > 8 byte
aligned memory based on the allocation size or if this has always been the case. I want to know if my program compiled with 3.9.1 also has a problem that was just not exposed in testing.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks in advance.<span class="m_-1376098337422870178HOEnZb"><font color="#888888"><u></u><u></u></font></span></p><span class="m_-1376098337422870178HOEnZb"><font color="#888888">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">/Riyaz<u></u><u></u></p>
</font></span></div>
</div>
<br></div></div>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>