<div dir="ltr"><span style="font-size:12.8px">> It won't give you an error (just a warning), but no-one I know thinks</span><br style="font-size:12.8px"><span style="font-size:12.8px">> doing anything special with it is a good idea. It's accepted purely</span><br style="font-size:12.8px"><span style="font-size:12.8px">> for compatibility I think.<br></span><span style="font-size:12.8px"><br>When I used -O3, I have got the below messages while building CoreCLR. <br><br> ...... Upper Omission ......</span><div><div style=""><span style="font-size:12.8px">Scanning dependencies of target dlltest1_exports</span></div><div style=""><span style="font-size:12.8px">clang: error: -O4 is equivalent to -O3</span></div><div style=""><span style="font-size:12.8px">make[2]: [ 0%] *** [src/debug/debug-pal/CMakeFiles/debug-pal.dir/unix/twowaypipe.cpp.o] Error 1</span></div><div style=""><span style="font-size:12.8px">make[2]: *** Waiting for unfinished jobs....</span></div><div style=""><span style="font-size:12.8px">Scanning dependencies of target System.Globalization.Native</span></div><div style=""><span style="font-size:12.8px">Scanning dependencies of target corguids</span></div><div style=""><span style="font-size:12.8px">[ 0%] Generating exports file /work/dotnet/coreclr.git/bin/obj/Linux.arm.Release/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/dlltest2.exports</span></div><div style=""><span style="font-size:12.8px">[ 0%] [ 0%] Generating exports file /work/dotnet/coreclr.git/bin/obj/Linux.arm.Release/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/dlltest1.exports</span></div><div style=""><span style="font-size:12.8px">Building CXX object src/pal/src/CMakeFiles/tracepointprovider.dir/misc/tracepointprovider.cpp.o</span></div><div style=""><span style="font-size:12.8px">Scanning dependencies of target unixcoreruncommon</span></div><div style=""><span style="font-size:12.8px">clang: error: -O4 is equivalent to -O3</span></div><div style=""><span style="font-size:12.8px">make[2]: *** [src/debug/debug-pal/CMakeFiles/debug-pal.dir/__/__/__/version.cpp.o] Error 1</span></div><div style=""><span style="font-size:12.8px">make[1]: *** [src/debug/debug-pal/CMakeFiles/debug-pal.dir/all] Error 2</span></div><div style=""><span style="font-size:12.8px">make[1]: *** Waiting for unfinished jobs....</span></div><div style=""><span style="font-size:12.8px">[ 0%] Built target dlltest2_exports</span></div><div style="font-size:12.8px"> ...... Below Omission ......</div><br><br><span style="font-size:12.8px">> I will share the evaluation result after comparing the generated instructions </span><br style="font-size:12.8px"><span style="font-size:12.8px">> between "with memcpy" and "without memcpy" case using simple C# file. </span><br><div><br></div><div>I have made two patches like below. After applying the below two patches, </div><div>I don't fact any bus errors compared to the existing status in case that I compiled CoreCLR with -O3 (clang-3.6).<br><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>Do I have to compare the generated instructions to find appropriate patch?<br><br></div><div><div><br></div><div>######## 1. with memcpy library call (need refactoring)</div><div><br></div><div>+++ b/src/jit/compiler.hpp</div><div>@@ -759,11 +759,19 @@ inline</div><div> </div><div> inline</div><div> signed __int32 getI4LittleEndian(const BYTE * ptr)</div><div>-{ return *(UNALIGNED signed __int32*)ptr; }</div><div>+{ </div><div>+ signed __int32 buffer;</div><div>+ memcpy(&buffer, ptr, 4); // 4 bytes</div><div>+ return buffer;</div><div>+}</div><div> </div><div> inline</div><div> signed __int64 getI8LittleEndian(const BYTE * ptr)</div><div>-{ return *(UNALIGNED signed __int64*)ptr; }</div><div>+{</div><div>+ signed __int64 buffer;</div><div>+ memcpy(&buffer, ptr, 8); // 8 bytes</div><div>+ return buffer;</div><div>+}</div><div> </div><div>######## 2. with attribute keyword (need refactoring) </div><div><br></div><div>+++ b/src/jit/compiler.hpp</div><div>@@ -757,13 +757,16 @@ inline</div><div> signed __int16 getI2LittleEndian(const BYTE * ptr)</div><div> { return * (UNALIGNED signed __int16 *)ptr; }</div><div> </div><div>+typedef signed __int32 __attribute__((aligned(1))) __unaligned_arm_int32;</div><div>+typedef signed __int64 __attribute__((aligned(1))) __unaligned_arm_int64;</div><div>+</div><div> inline</div><div> signed __int32 getI4LittleEndian(const BYTE * ptr)</div><div>-{ return *(UNALIGNED signed __int32*)ptr; }</div><div>+{ return *(__unaligned_arm_int32 *)ptr; }</div><div> </div><div> inline</div><div> signed __int64 getI8LittleEndian(const BYTE * ptr)</div><div>-{ return *(UNALIGNED signed __int64*)ptr; }</div><div>+{ return *(__unaligned_arm_int64 *)ptr; }</div><div> </div></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 14, 2016 at 11:28 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 class="">On 13 July 2016 at 21:14, Geunsik Lim <<a href="mailto:leemgs@gmail.com">leemgs@gmail.com</a>> wrote:<br>
> Thank you for sharing the FreeBSD manpage. BTW, Is O4 flag available now?<br>
> * -O4 and higher: Currently equivalent to -O3<br>
<br>
</span>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>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></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>