Linux/ARM: Bus error with -O3 flag of clang/llvm-3.6 while running unit-test of .NET Core

[Geunsik Lim via llvm-commits]

> It won't give you an error (just a warning), but no-one I know thinks
>  doing anything special with it is a good idea. It's accepted purely
> for compatibility I think.

When I used -O3, I have got the below messages while building CoreCLR.

 ...... Upper Omission ......
Scanning dependencies of target dlltest1_exports
clang: error: -O4 is equivalent to -O3
make[2]: [  0%] ***
[src/debug/debug-pal/CMakeFiles/debug-pal.dir/unix/twowaypipe.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
Scanning dependencies of target System.Globalization.Native
Scanning dependencies of target corguids
[  0%] Generating exports file
/work/dotnet/coreclr.git/bin/obj/Linux.arm.Release/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/dlltest2.exports
[  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
Building CXX object
src/pal/src/CMakeFiles/tracepointprovider.dir/misc/tracepointprovider.cpp.o
Scanning dependencies of target unixcoreruncommon
clang: error: -O4 is equivalent to -O3
make[2]: ***
[src/debug/debug-pal/CMakeFiles/debug-pal.dir/__/__/__/version.cpp.o] Error
1
make[1]: *** [src/debug/debug-pal/CMakeFiles/debug-pal.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[  0%] Built target dlltest2_exports
  ...... Below Omission ......


> I will share the evaluation result after comparing the generated
instructions
> between "with memcpy" and "without memcpy" case using simple C# file.

I have made two patches like below. After applying the below two patches,
I don't fact any bus errors compared to the existing status in case that I
compiled CoreCLR with -O3 (clang-3.6).

I am not sure which solution is better between the below two patches.
Could you tell me comment to get the best way?
Do I have to compare the generated instructions to find appropriate patch?


######## 1. with memcpy library call (need refactoring)

+++ b/src/jit/compiler.hpp
@@ -759,11 +759,19 @@ inline

 inline
   signed __int32    getI4LittleEndian(const BYTE * ptr)
-{ return *(UNALIGNED signed __int32*)ptr; }
+{
+    signed __int32 buffer;
+    memcpy(&buffer, ptr, 4); // 4 bytes
+    return buffer;
+}

 inline
   signed __int64    getI8LittleEndian(const BYTE * ptr)
-{ return *(UNALIGNED signed __int64*)ptr; }
+{
+    signed __int64 buffer;
+    memcpy(&buffer, ptr, 8); // 8 bytes
+    return buffer;
+}

######## 2. with attribute keyword (need refactoring)

+++ b/src/jit/compiler.hpp
@@ -757,13 +757,16 @@ inline
   signed __int16    getI2LittleEndian(const BYTE * ptr)
 { return * (UNALIGNED signed __int16 *)ptr; }

+typedef signed __int32 __attribute__((aligned(1))) __unaligned_arm_int32;
+typedef signed __int64 __attribute__((aligned(1))) __unaligned_arm_int64;
+
 inline
   signed __int32    getI4LittleEndian(const BYTE * ptr)
-{ return *(UNALIGNED signed __int32*)ptr; }
+{ return *(__unaligned_arm_int32 *)ptr; }

 inline
   signed __int64    getI8LittleEndian(const BYTE * ptr)
-{ return *(UNALIGNED signed __int64*)ptr; }
+{ return *(__unaligned_arm_int64 *)ptr; }



On Thu, Jul 14, 2016 at 11:28 PM, Tim Northover <t.p.northover at gmail.com>
wrote:

> On 13 July 2016 at 21:14, Geunsik Lim <leemgs at gmail.com> wrote:
> > Thank you for sharing the FreeBSD manpage. BTW, Is O4 flag available now?
> > * -O4 and higher: Currently equivalent to -O3
>
> It won't give you an error (just a warning), but no-one I know thinks
> doing anything special with it is a good idea. It's accepted purely
> for compatibility I think.
>
> Tim.
>



-- 
http://leemgs.fedorapeople.org
Don't try to avoid pain if you fail.
If you decided to face the challenges in life,
you can gain a lot by giving your best.
Cheolsang Jeong's Book & life
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160715/ee985bdc/attachment.html>