Bug 221588 - clang crashes when compiling cad/openvsp
Summary: clang crashes when compiling cad/openvsp
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-toolchain mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-17 13:11 UTC by Fernando Apesteguía
Modified: 2017-09-02 18:01 UTC (History)
3 users (show)

See Also:


Attachments
clang crash debug file (962.40 KB, text/x-c++src)
2017-08-17 13:11 UTC, Fernando Apesteguía
no flags Details
clang crash debug file (3.09 KB, application/x-shellscript)
2017-08-17 13:12 UTC, Fernando Apesteguía
no flags Details
Disable prologs/epilogs that crash clang (8.21 KB, patch)
2017-08-23 20:54 UTC, Dimitry Andric
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Fernando Apesteguía freebsd_committer 2017-08-17 13:11:55 UTC
Created attachment 185523 [details]
clang crash debug file

One of my ports (cad/openvsp) fails to compile in -CURRENT. The port
only compiles with gcc on < 12. As part of the debugging I changed to
compile with clang.

The compiler crashed while compiling the port with the following error:

fatal error: error in backend: No open frame
c++: error: clang frontend command failed with exit code 70

Compiler version is:

freebsd clang version 5.0.0 (brances/release_50 309439)

FreeBSD CURRENT is running in virtualbox 5.1.22 with 8GB of memory assigned. I didn't see any symptoms of memory exhaustion.

How to reproduce:

Change compiler:gcc-c++11-lib to compiler:c++14-lang in port's Makefile

Change src/external/glfont2/CMakeLists.txt and add /usr/local/include
(for some reason clang doesn't find GL/gl.h while gcc does...)
Comment 1 Fernando Apesteguía freebsd_committer 2017-08-17 13:12:24 UTC
Created attachment 185524 [details]
clang crash debug file
Comment 2 Dimitry Andric freebsd_committer 2017-08-17 17:26:32 UTC
So what this test case causes is:

fatal error: error in backend: No open frame

This happens with most versions of clang that I could test, and is due to the following inline assembly:

https://sourceforge.net/p/angelscript/code/HEAD/tree/trunk/sdk/angelscript/source/as_callfunc_x86.cpp#l1454

#ifdef __OPTIMIZE__
                // Epilogue
                "movl %%ebp, %%esp         \n"
                ".cfi_def_cfa_register esp \n"
                "popl %%ebp                \n"
                ".cfi_adjust_cfa_offset -4 \n"
                ".cfi_restore ebp          \n"
#endif

Basically, it finds a 'naked' .cfi_restore directive, and it chokes on that. It is probably possible to work around this by disabling the epilogue part, but I am not familiar with this angelscript stuff at all...

We do have a lang/angelscript port, maintained by vg@, maybe he knows how we can work around this problem?
Comment 3 Dimitry Andric freebsd_committer 2017-08-23 20:54:53 UTC
Created attachment 185701 [details]
Disable prologs/epilogs that crash clang

Here is a patch which disables the strange prologs/epilogs that mess with the CFI state, and cause clang to crash.  I ran the resulting vsp executable, and it seemed to work OK for me, with light testing.
Comment 4 Fernando Apesteguía freebsd_committer 2017-09-02 16:42:44 UTC
Closing the PR since I opened another one with an update of the port so it compiles in -CURRENT. See:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222001

I tested the unpatched port with clang 5.0.0 r312293 and clang still crashes. I didn't see a but report in llvm's bugzilla. Has this been reported?
Comment 5 Dimitry Andric freebsd_committer 2017-09-02 18:01:46 UTC
(In reply to fernando.apesteguia from comment #4)
> Closing the PR since I opened another one with an update of the port so it
> compiles in -CURRENT. See:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222001
> 
> I tested the unpatched port with clang 5.0.0 r312293 and clang still
> crashes. I didn't see a but report in llvm's bugzilla. Has this been
> reported?

No, this code makes no sense, so it also makes no real sense to report it. Just apply the patch.