Bug 214592

Summary: clang 3.9 crashes while cross-compiling for armv6
Product: Ports & Packages Reporter: Jan Beich <jbeich>
Component: Individual Port(s)Assignee: Dimitry Andric <dim>
Status: Closed Works As Intended    
Severity: Affects Only Me CC: Andrew, FreeBSD
Priority: --- Keywords: regression
Version: Latest   
Hardware: Any   
OS: Any   
Bug Depends on:    
Bug Blocks: 212343    
Description Flags
platform/x11/context_gl_x11.cpp (preprocessed, compressed)
context_gl_x11.sh (compiler args) none

Description Jan Beich freebsd_committer 2016-11-17 00:14:17 UTC
Created attachment 177099 [details]
platform/x11/context_gl_x11.cpp (preprocessed, compressed)

Assertion failed: ((!TM.getMCAsmInfo() || (TM.getMCAsmInfo()->getExceptionHandlingType() == Exception
Handling::SjLj) == UseSjLjEH) && "inconsistent sjlj choice between CodeGen and MC"), function initial
izeEnvironment, file /usr/src/contrib/llvm/lib/Target/ARM/ARMSubtarget.cpp, line 111.

/projects/clang390-import@308491 here.
Comment 1 Jan Beich freebsd_committer 2016-11-17 00:15:11 UTC
Created attachment 177100 [details]
context_gl_x11.sh (compiler args)
Comment 2 Jan Beich freebsd_committer 2016-11-17 00:17:42 UTC
/head is still using clang 3.8 which is NOT affected.
Comment 3 Andrew Turner freebsd_committer 2016-11-17 13:33:11 UTC
Why is it setting -fsjlj-exceptions? We haven't used them since FreeBSD 9.
Comment 4 Dimitry Andric freebsd_committer 2016-11-17 20:23:43 UTC
Actually the test case can be zero bytes, it's only about the command line arguments, which specify -fsjlj-exceptions, while the target is armv6kz--freebsd.  Since we removed sjlj support from FreeBSD/arm in 10.x, we now only support EABI, and this conflict is noted by the following upstream addition:


"ARM: make sure backend is consistent about exception handling method.

It turns out we decide whether to use SjLj exceptions or some alternative in
two separate places in the backend, and they disagreed with each other. This
led to inconsistent code and is generally a terrible idea."

I've understood from Andy that this is likely caused by passing -m32, but I don't know how the port does this.
Comment 5 Jan Beich freebsd_committer 2016-11-17 20:50:29 UTC
(In reply to Dimitry Andric from comment #4)
> I've understood from Andy that this is likely caused by passing
> -m32, but I don't know how the port does this.

It does not. Actually, comment 0 was discovered via bug 214553 while playing with cross-compiler. The following crashes

  $ clang++ -target armv6--freebsd12.0 -c context_gl_x11-271f43.cpp

but chrooting into clang39-armv6 jail and dropping -target does not.

--- native  clang++ -dM -E -</dev/null
+++ cross   clang++ -target armv6--freebsd12.0 -dM -E -</dev/null
@@ -18,7 +18,6 @@
 #define __ARM_FP16_ARGS 1
 #define __ARM_FP16_FORMAT_IEEE 1
 #define __ARM_PCS 1
-#define __ARM_PCS_VFP 1
 #define __ARM_SIZEOF_WCHAR_T 4
 #define __ARM_VFPV2__ 1
@@ -208,6 +207,7 @@
 #define __SIZE_MAX__ 4294967295U
 #define __SIZE_TYPE__ unsigned int
 #define __SIZE_WIDTH__ 32
+#define __SOFTFP__ 1
 #define __STDC_HOSTED__ 1
 #define __STDC_MB_MIGHT_NEQ_WC__ 1
 #define __STDC_UTF_16__ 1
@@ -307,6 +307,7 @@
 #define __UINT_LEAST8_MAX__ 255
 #define __UINT_LEAST8_TYPE__ unsigned char
 #define __USER_LABEL_PREFIX__ 
 #define __VERSION__ "4.2.1 Compatible FreeBSD Clang 3.9.0 (tags/RELEASE_390/final 280324)"
 #define __VFP_FP__ 1
 #define __WCHAR_MAX__ 4294967295U
Comment 6 Jan Beich freebsd_committer 2016-11-17 21:09:42 UTC
-target armv6kz--freebsd12.0-gnueabihf doesn't crash which is what head-armv6 currently uses according to "cc -v".