On Wed, 29 Nov 2017, Reid Kleckner wrote:
On Wed, Nov 29, 2017 at 12:21 PM, Martin Storsjö <mar...@martin.st> wrote:
On Wed, 29 Nov 2017, Martell Malone via cfe-commits wrote:
Thanks for letting me know Reid.
I’ll in work and won’t be able to access the repo
until lunch time. (~3
hours)
Feel free to revert if it is not trivial.
The easy fix might be to change to == x86_64 from !=
x86 For is Windows in
the default toolchain. That should restore the old
behavior.
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?
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.
No, I think this change makes sense - I was just about to write a comment
pointing out this spot in the code but was waiting for a compile to finish
before posting.
Alternatively, you could view -fseh-exceptions, -fdwarf-exceptions, and
-fsjlj-exceptions as choices of EH personality function,
No, I don't think that'd make sense
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.
My point was that for the MSVC mode, this worked fine before since this
was the default behaviour - avoiding passing any option (i.e. having that
function return None) should be a safe way to keep things working as it
did before. But then it would break again if -fseh-exceptions were passed,
which I would expect to be a no-op in such a configuration.
My remaining concern is mostly about why we still need the workaround for
x86 in the function getting the default (returning None instead of WinEH
for that case). But as long as this works and the rest of this change can
settle, we can look at that later if any further change is warranted at
all.
// Martin
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
