Bug 214592 - clang 3.9 crashes while cross-compiling for armv6
Summary: clang 3.9 crashes while cross-compiling for armv6
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Dimitry Andric
URL:
Keywords: regression
Depends on:
Blocks: 212343
  Show dependency treegraph
 
Reported: 2016-11-17 00:14 UTC by Jan Beich
Modified: 2016-11-17 21:09 UTC (History)
2 users (show)

See Also:


Attachments
platform/x11/context_gl_x11.cpp (preprocessed, compressed) (236.80 KB, application/x-xz)
2016-11-17 00:14 UTC, Jan Beich
no flags Details
context_gl_x11.sh (compiler args) (4.36 KB, text/plain)
2016-11-17 00:15 UTC, Jan Beich
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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:

http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMSubtarget.cpp?r1=253502&r2=253501&pathrev=253502

"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_MINIMAL_ENUM 4
 #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 __USING_SJLJ_EXCEPTIONS__ 1
 #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".