Exceptions on Windows & MSVC

At Microsoft we open sourced some of our compiler tests for exception handling on github.

https://github.com/microsoft/compiler-tests

We are looking into what it would take to get these to work with clang-cl. I’m planning to share a design document on the mailing list soon.

Aaron

Good to hear. I re-ran the C++ EH tests locally a few months ago with clang-cl. Most of the tests passed, but some failed. For the ones that failed, it wasn’t immediately clear if it was an EH bug or not. It seemed like clang was doing more copy elision than MSVC, and that accounted for most of the variation. It would be good to get to the bottom of it and be certain, though. In the end it runs fast enough that we could run it continuously.

I tried compiling the source files under “SEH” with the latest official version of Clang-Cl and Visual Studio 2015. Compiling:

seh0015.c

seh0017.c

seh0035.c

seh0034.c

seh0036.c

seh0041.c

seh0043.c

seh0042.c

seh0049.c

seh0048.c

seh0050.c

xcpt4u.c

Will crash the compiler with “clang frontend command failed due to signal (use -v to see invocation)” and a stack dump.
Am I the only one having that issue?

Thank you for this Aaron!

In our company we rely heavily on the compatibility between Clang-Cl and the Visual Studio compiler, lately we encountered big problems with the handling of SEH exceptions in our code, so running those tests helped us. (Sadly we can’t move to the Visual Studio compiler)

However, maybe it helps someone if I share the results from running those tests… I imported all of the tests into separated projects, compiling them with the same settings, with MSVC (v141) and Clang (9), then I compared the output. The compiler settings for all those projects were:

/permissive- /GS /GL /W3 /Gy /Zc:wchar_t /Gm- /Ox /Ob2 /sdl /Zc:inline /fp:precise /D “_MBCS” /errorReport:prompt /GF- /WX- /Zc:forScope /Gd /Oy /Oi /MD /FC /EHsc /nologo /Ot /diagnostics:classic

The MSVC compiler only failed the following test:

EH:
ihateeh.cxx

Clang however failed multiple tests:
EH:

ihateeh.cxx

SEH:

seh0007.c (-> Test failed; The access violation was optimized away, leading to a random result; – forcing the access violation caused no catching of the exception)
seh0019.c (-> No exception caught; Which makes sense because there are no catch handler, but MSVC does catch them)
seh0055.c (-> Test failed; The result is not correct)

sehframes.cpp (-> A certain exception was not caught)

The following tests didn’t even compiled, instead they crashed the compiler:

seh0034.c

seh0035.c

seh0036.c

seh0041.c

seh0042.c

seh0043.c

seh0048.c

seh0049.c

seh0050.c
xcpt4u.c

I hope that helped in some way – any comments or suggestions? I’m up for it!

Here is a wiki page and git repo with an implementation of SEH that passes all the tests for x86.
We’re looking for feedback before putting a patch on Phabricator.

https://github.com/tentzen/llvm-project
https://github.com/tentzen/llvm-project/wiki

Oh woah! That is really really cool! I hope I can try this out soon >o<

What is the Phabricator?

Hey Aaron,

I downloaded the source files from the git repo and build the LLVM and Clang with it. It is awesome to see that the SEH tests from Microsoft are working now. However Clang still crashes when trying to compile the “xcpt4u.c” source file from the SEH tests. I did a small source code modification by changing the return statement of the main to “return 0;”

Is this test supposed to work? Have I misconfigured something?

Kind greetings

Björn

There are five bugs (three left) that are being fixed. Test58 & Test61 were fixed in Ten’s last commit.

Both pass the entire SEH test suite except the following failures:
   -- Xcpt4u: test58 & test61:  due to Nested_Finally, a missing feature of
              present compiler. On MSVC this feature is only valid on X64 target.
   -- Xcpt4u: test84 & test87: leaving an except handler must invoke _local_unwind().
   -- Seh0020 (-O2 only):  a present setjmp/longjmp bug.