<div dir="ltr">I would like to thank Tim Northover and Renato Golin for their valuable feedback on this issue. <br>Below is the execution result of the 9873 unit tests after generating CoreCLR with -O3 flag. <br>I hope that clang/llvm developers can fix easily a similar case via this emailing list.<br>( For example, jackd1: bus error on beagleboard - <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692562">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692562</a> )<br><br>However, I am not sure why we can not resolve this issue on LLVM back-end without CoreCLR level. <br><br><div><br></div><div>* Before applying the patch: </div><div>=======================</div><div> Test Results (Release Build + O3)</div><div>=======================</div><div># CoreCLR Bin Dir : /unit-test/bin.coreclr.release.20160713.1.O3/Product/Linux.arm.Release</div><div># Tests Discovered : 9873</div><div># Passed : 5626</div><div># Failed : 3886 (commit: 20160627-52570683, OOM: 1, manual kill commands: 7 ) <==== HERE!!!</div><div># Skipped : 361</div><div>=======================</div><div>102 minutes and 10 seconds taken to run CoreCLR tests.</div><div><br></div><div>real<span class="" style="white-space:pre"> </span>103m44.120s</div><div>user<span class="" style="white-space:pre"> </span>256m19.410s</div><div>sys<span class="" style="white-space:pre"> </span>13m29.340s</div><div>root@arm-target:/unit-test/coreclr.git/tests# </div><div><br></div><div><br></div><div>* After applying the patch: </div><div>=======================</div><div> Test Results (Release Build + O3)</div><div>=======================</div><div># CoreCLR Bin Dir : /unit-test/bin.coreclr.release.20160713.1.O3.memcopy/Product/Linux.arm.Release</div><div># Tests Discovered : 9873</div><div># Passed : 9465</div><div># Failed : 47 (commit: 20160627-52570683, OOM: 2, manual kill commands: 0 ) <==== HERE!!!</div><div># Skipped : 361</div><div>=======================</div><div>117 minutes and 47 seconds taken to run CoreCLR tests.</div><div><br></div><div>real<span class="" style="white-space:pre"> </span>119m25.213s</div><div>user<span class="" style="white-space:pre"> </span>146m25.355s</div><div>sys<span class="" style="white-space:pre"> </span>16m38.915s</div><div>root@arm-target:/unit-test/coreclr.git/tests# </div><div><br></div><div>BRs,</div><div>Geunsik Lim. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 3:35 PM, Geunsik Lim <span dir="ltr"><<a href="mailto:leemgs@gmail.com" target="_blank">leemgs@gmail.com</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"><span class="">> <span style="font-size:12.8px">Presumably CoreCLR builds with -Werror, <br></span></span>Right. <div><br></div><div><span class="">> <span style="font-size:12.8px">But there's really no reason to use -O4 in the first place </span></span><span style="font-size:12.8px">since it's identical to -O3.<br>Actually, I thought that -O4</span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">means "link-time optimization" based on -O3 </span><span style="font-size:12.8px"> (e.g., -</span><span style="font-size:12.8px">O3 + -flto ). </span><span class=""><span style="font-size:12.8px"><br><br><br>> </span><span style="font-size:12.8px">When I grepped CoreCLR I saw rather</span><br style="font-size:12.8px"><span style="font-size:12.8px">> more uses of UNALIGNED than the two functions you've patched.</span><br></span><span style="font-size:12.8px">Yes, So, It seems that we have to add an exception handling to proceed arm-specific condition in case of -O3(clang) as following:</span><br><br><div><span style="font-size:12.8px">---</span><br></div><div><span style="font-size:12.8px"> src/jit/compiler.hpp | 8 ++++----</span></div><div><span style="font-size:12.8px"> src/pal/inc/pal.h | 6 ++++++</span></div><div><span style="font-size:12.8px"> 2 files changed, 10 insertions(+), 4 deletions(-)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">diff --git a/src/jit/compiler.hpp b/src/jit/compiler.hpp</span></div><div><span style="font-size:12.8px">index 7a16b7c..8cee77e 100644</span></div><div><span style="font-size:12.8px">--- a/src/jit/compiler.hpp</span></div><div><span style="font-size:12.8px">+++ b/src/jit/compiler.hpp</span></div><div><span style="font-size:12.8px">@@ -757,16 +757,16 @@ inline</span></div><span class=""><div><span style="font-size:12.8px"> signed __int16 getI2LittleEndian(const BYTE * ptr)</span></div><div><span style="font-size:12.8px"> { return * (UNALIGNED signed __int16 *)ptr; }</span></div><div><span style="font-size:12.8px"> </span></div></span><div><span style="font-size:12.8px">-typedef signed __int32 __attribute__((aligned(1))) __unaligned_arm_int32;</span></div><div><span style="font-size:12.8px">-typedef signed __int64 __attribute__((aligned(1))) __unaligned_arm_int64;</span></div><div><span style="font-size:12.8px">+typedef signed __int32 UNALIGNED_ARM __unaligned_int32;</span></div><div><span style="font-size:12.8px">+typedef signed __int64 UNALIGNED_ARM __unaligned_int64;</span></div><span class=""><div><span style="font-size:12.8px"> </span></div><div><span style="font-size:12.8px"> inline</span></div><div><span style="font-size:12.8px"> signed __int32 getI4LittleEndian(const BYTE * ptr)</span></div></span><div><span style="font-size:12.8px">-{ return *(__unaligned_arm_int32 *)ptr; }</span></div><div><span style="font-size:12.8px">+{ return *(__unaligned_int32 *)ptr; }</span></div><span class=""><div><span style="font-size:12.8px"> </span></div><div><span style="font-size:12.8px"> inline</span></div><div><span style="font-size:12.8px"> signed __int64 getI8LittleEndian(const BYTE * ptr)</span></div></span><div><span style="font-size:12.8px">-{ return *(__unaligned_arm_int64 *)ptr; }</span></div><div><span style="font-size:12.8px">+{ return *(__unaligned_int64 *)ptr; }</span></div><span class=""><div><span style="font-size:12.8px"> </span></div><div><span style="font-size:12.8px"> inline</span></div><div><span style="font-size:12.8px"> float getR4LittleEndian(const BYTE * ptr)</span></div></span><div><span style="font-size:12.8px">diff --git a/src/pal/inc/pal.h b/src/pal/inc/pal.h</span></div><div><span style="font-size:12.8px">index 5b44661..b95d74c 100644</span></div><div><span style="font-size:12.8px">--- a/src/pal/inc/pal.h</span></div><div><span style="font-size:12.8px">+++ b/src/pal/inc/pal.h</span></div><div><span style="font-size:12.8px">@@ -201,7 +201,13 @@ extern "C" {</span></div><div><span style="font-size:12.8px"> </span></div><div><span style="font-size:12.8px"> #else // _MSC_VER</span></div><div><span style="font-size:12.8px"> </span></div><div><span style="font-size:12.8px">+#if defined (_M_ARM) && !defined (DEBUG)</span></div><div><span style="font-size:12.8px"> #define UNALIGNED</span></div><div><span style="font-size:12.8px">+#define UNALIGNED_ARM __attribute__((aligned(1))) //for -O2 and -O3</span></div><div><span style="font-size:12.8px">+#else</span></div><div><span style="font-size:12.8px">+#define UNALIGNED</span></div><div><span style="font-size:12.8px">+#define UNALIGNED_ARM //for -O0</span></div><div><span style="font-size:12.8px">+#endif</span></div><div><span style="font-size:12.8px"> </span></div><div><span style="font-size:12.8px"> #endif // _MSC_VER</span></div><div><span style="font-size:12.8px"> </span></div><div><span style="font-size:12.8px">-- </span></div><div><span style="font-size:12.8px">1.9.1</span></div><span class=""><br><span style="font-size:12.8px"> </span><br><span style="font-size:12.8px">>> Do I have to compare the generated instructions to find appropriate patch?<br>> </span><span style="font-size:12.8px">I'd expect them to be equivalent after optimization</span></span><span style="font-size:12.8px"><br>Do you mean that we get the similar instructions between "memcpy()" library call <br>and " __attribute__(aligned(1)) keyword".<br><br>Thanks. </span><div><span style="font-size:12.8px"><br><br>BRs,<br>Geunsik Lim. </span><div><span style="font-size:12.8px"><br><br></span></div></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 12:00 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 14 July 2016 at 19:47, Geunsik Lim <<a href="mailto:leemgs@gmail.com" target="_blank">leemgs@gmail.com</a>> wrote:<br>
>> It won't give you an error (just a warning), but no-one I know thinks<br>
>> doing anything special with it is a good idea. It's accepted purely<br>
>> for compatibility I think.<br>
><br>
> When I used -O3, I have got the below messages while building CoreCLR.<br>
<br>
</span>Presumably CoreCLR builds with -Werror, which turns any warning into<br>
an error. But there's really no reason to use -O4 in the first place<br>
since it's identical to -O3.<br>
<span><br>
> I am not sure which solution is better between the below two patches.<br>
> Could you tell me comment to get the best way?<br>
<br>
</span>A lot of it comes down to personal preference. Both approaches are<br>
functional but you'd have to ask the CoreCLR developers which they<br>
prefer.<br>
<br>
One thing to be wary of is that those patches look like very partial<br>
fixes. They may get rid of the current segfault, but leave the<br>
underlying problem open in other places (just waiting for some minor<br>
change in Clang to trigger it). When I grepped CoreCLR I saw rather<br>
more uses of UNALIGNED than the two functions you've patched.<br>
<span><br>
> Do I have to compare the generated instructions to find appropriate patch?<br>
<br>
</span>I'd expect them to be equivalent after optimization.<br>
<span><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="">-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><a href="http://leemgs.fedorapeople.org" style="font-family:Tahoma" target="_blank">http://leemgs.fedorapeople.org</a><span style="font-family:Tahoma"> </span></div><div>Don't try to avoid pain if you fail.<br>If you decided to face the challenges in life, <br>you can gain a lot by giving your best.<br>Cheolsang Jeong's Book & life<br>--<br></div></div></div>
</span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><a href="http://leemgs.fedorapeople.org" style="font-family:Tahoma" target="_blank">http://leemgs.fedorapeople.org</a><span style="font-family:Tahoma"> </span></div><div>Don't try to avoid pain if you fail.<br>If you decided to face the challenges in life, <br>you can gain a lot by giving your best.<br>Cheolsang Jeong's Book & life<br>--<br></div></div></div>
</div>