<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 29, 2017 at 12:21 PM, Martin Storsjö <span dir="ltr"><<a href="mailto:martin@martin.st" target="_blank">martin@martin.st</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Wed, 29 Nov 2017, Martell Malone via cfe-commits wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for letting me know Reid.<br>
I’ll in work and won’t be able to access the repo until lunch time. (~3<br>
hours)<br>
Feel free to revert if it is not trivial.<br>
<br>
The easy fix might be to change to == x86_64 from != x86 For is Windows in<br>
the default toolchain. That should restore the old behavior.<br>
</blockquote>
<br></span>
My suggestion would be to just return None for all architectures for the default windows (msvc) case. We didn't use to set any defines to indicate EH mode there before anyway, so setting it to None should make things behave just as before, right?</blockquote><div><br></div><div>I did this slightly differently in r319363, but maybe that's silly. My reasoning was that `clang -cc1 -fseh-exceptions -fexceptions` in the MSVC environment should still use __CxxFrameHandler3. -fseh-exceptions indicates what format of unwind information we should use, and we're still using the normal SEH .xdata opcodes.</div><div><br></div><div>Alternatively, you could view -fseh-exceptions, -fdwarf-exceptions, and -fsjlj-exceptions as choices of EH personality function, in which case, my change is wrong, and we should do what you guys were suggesting and stop passing this from the driver. Hard to say.</div></div></div></div>