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

[Geunsik Lim via llvm-commits]

> Presumably CoreCLR builds with -Werror,
Right.

> But there's really no reason to use -O4 in the first place since it's
identical to -O3.
Actually, I thought that -O4 means "link-time optimization" based on
-O3  (e.g.,
-O3 + -flto ).


> When I grepped CoreCLR I saw rather
> more uses of UNALIGNED than the two functions you've patched.
Yes, So, It seems that we have to add an exception handling  to proceed
arm-specific condition in case of -O3(clang) as following:

---
 src/jit/compiler.hpp | 8 ++++----
 src/pal/inc/pal.h    | 6 ++++++
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/jit/compiler.hpp b/src/jit/compiler.hpp
index 7a16b7c..8cee77e 100644
--- a/src/jit/compiler.hpp
+++ b/src/jit/compiler.hpp
@@ -757,16 +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;
+typedef signed __int32 UNALIGNED_ARM __unaligned_int32;
+typedef signed __int64 UNALIGNED_ARM __unaligned_int64;

 inline
   signed __int32    getI4LittleEndian(const BYTE * ptr)
-{ return *(__unaligned_arm_int32 *)ptr; }
+{ return *(__unaligned_int32 *)ptr; }

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

 inline
 float               getR4LittleEndian(const BYTE * ptr)
diff --git a/src/pal/inc/pal.h b/src/pal/inc/pal.h
index 5b44661..b95d74c 100644
--- a/src/pal/inc/pal.h
+++ b/src/pal/inc/pal.h
@@ -201,7 +201,13 @@ extern "C" {

 #else // _MSC_VER

+#if defined (_M_ARM) && !defined (DEBUG)
 #define UNALIGNED
+#define UNALIGNED_ARM     __attribute__((aligned(1))) //for -O2 and -O3
+#else
+#define UNALIGNED
+#define UNALIGNED_ARM  //for -O0
+#endif

 #endif // _MSC_VER

-- 
1.9.1


>> Do I have to compare the generated instructions to find appropriate
patch?
> I'd expect them to be equivalent after optimization
Do you mean that we get the similar instructions between "memcpy()"
 library call
and " __attribute__(aligned(1)) keyword".

Thanks.


BRs,
Geunsik Lim.



On Fri, Jul 15, 2016 at 12:00 PM, Tim Northover <t.p.northover at gmail.com>
wrote:

> On 14 July 2016 at 19:47, Geunsik Lim <leemgs at gmail.com> wrote:
> >> 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.
>
> Presumably CoreCLR builds with -Werror, which turns any warning into
> an error. But there's really no reason to use -O4 in the first place
> since it's identical to -O3.
>
> > I am not sure which solution is better between the below two patches.
> > Could you tell me comment to get the best way?
>
> A lot of it comes down to personal preference. Both approaches are
> functional but you'd have to ask the CoreCLR developers which they
> prefer.
>
> One thing to be wary of is that those patches look like very partial
> fixes. They may get rid of the current segfault, but leave the
> underlying problem open in other places (just waiting for some minor
> change in Clang to trigger it). When I grepped CoreCLR I saw rather
> more uses of UNALIGNED than the two functions you've patched.
>
> > Do I have to compare the generated instructions to find appropriate
> patch?
>
> I'd expect them to be equivalent after optimization.
>
> 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/20160718/fb01f06c/attachment.html>